--
On Sun, 08 Sep 2002 22:24:11
Damian Conway wrote:
>
>Think of it as punctuation. As a necessary alternative to the poor
>overworked colon.
>
Or the poor overworked dot?
>
>
>> it all looks the same to me. And I like different things to look different.
>
>A fair point. My counterargume
Steve Canfield wrote:
> I was under the impression that compile time properties, like runtime
> properties, can be arbitrarily invented and/or assigned.
Yes, but not purely lower-case ones. They're reserved for Perl 6 itself.
(i.e. only Larry can invent/assign them ;-)
> If that is
> correct,
>From: Uri Guttman <[EMAIL PROTECTED]>
>that is not a variable property so it should be
>a compile time error.
I was under the impression that compile time properties, like runtime
properties, can be arbitrarily invented and/or assigned. If that is
correct, why would "my $var is true", meaningle
Erik Steven Harrison wrote:
> But still, what counts as a runtime property, other than true or
> false, as in the delightful '0 but true'? What other kind of runtime
> labels can I slap on a value?
Here's ten to start with...
for <> but tainted(0) {...} # note that external data
Erik Steven Harrison wrote:
> Just found this hidden in my inbox.
> I didn't think anyone was paying attention ;-).
Oh, we *always* pay attention. We just don't always respond. ;-)
>>What I most like about the C syntax is (like methods in
>>OO Perl), it associates a meaningful *name* with e
> "SC" == Steve Canfield <[EMAIL PROTECTED]> writes:
SC> Would it be accurate to say that "is" sets properties of variables,
SC> whereas "but" sets properties of values? If so, what would this output:
SC> my $var is true;
that is not a variable property so it should be a compile tim
>From: Trey Harris <[EMAIL PROTECTED]>
>To: Steve Canfield <[EMAIL PROTECTED]>
> > I would expect it to output "false".
>
>Why? I believe that, whatever you set $var to, you have marked the
>variable as constantly true in booleans.
Because in my experience variables are not true or false. They
In a message dated Sun, 8 Sep 2002, Steve Canfield writes:
> Would it be accurate to say that "is" sets properties of variables, whereas
> "but" sets properties of values? If so, what would this output:
>
> my $var is true;
> $var=0;
> if ($var) {print "true"}
> else {print "false"}
>
> I
Would it be accurate to say that "is" sets properties of variables, whereas
"but" sets properties of values? If so, what would this output:
my $var is true;
$var=0;
if ($var) {print "true"}
else {print "false"}
I would expect it to output "false".
__
Peter Behroozi wrote:
>> sub hidden (str $name, int $force is aka($override)) {...}
>
>
> Hang on a moment! In your original answer to this question, you used
> the "is named('alias')" syntax, but now you are suggesting using the
> sigil in the syntax.
Yes, but for a *different* property.
> Damian Conway wrote:
> >>And is the is/but distinction still around?
> >
> >Oh, yes.
>
> Could someone please reference where this decision was
> made. I do not find any information describing the distinction.
The following May 2001 post was related. Poke around the
thread it was in, especial
Damian Conway wrote:
>>And is the is/but distinction still around?
>
>Oh, yes.
Could someone please reference where this decision was made. I do not find
any information describing the distinction.
Steve
_
Join the worlds larges
--
On Thu, 05 Sep 2002 09:26:08
Damian Conway wrote:
>Erik Steven Harrison wrote:
>
>
>> Is it just me or is the 'is' property syntax a little
>> too intuitive? Seems like everywhere I turn, the
>> proposed syntax to solve a problem is to apply a
>> property.
>
>That's because most of th
reposted because my mailer is evil
--
On Thu, 05 Sep 2002 09:31:45
Damian Conway wrote:
>Erik Steven Harrison wrote:
>
>> I know that the property syntax is pseudo established,
>> but I'm beggining to become a bit jaded about all the
>> built in properties were building. What about good ol'
--
On Thu, 05 Sep 2002 09:31:45
Damian Conway wrote:
>Erik Steven Harrison wrote:
>
>> I know that the property syntax is pseudo established,
>> but I'm beggining to become a bit jaded about all the
>> built in properties were building. What about good ol'
>> aliases?
>>
>> sub hidden (s
Erik Steven Harrison:
# But still, what counts as a runtime property, other than true or
# false, as in the delightful '0 but true'? What other kind of runtime
# labels can I slap on a value?
These occur to me:
$foo=0 but string("zero");
$bar='foobar' but num(1);
$baz=1
On Thu, 2002-09-05 at 04:31, Damian Conway wrote:
>sub hidden (str $name, int $force is aka($override)) {...}
Hang on a moment! In your original answer to this question, you used
the "is named('alias')" syntax, but now you are suggesting using the
sigil in the syntax. So, should it really b
Erik Steven Harrison wrote:
> I know that the property syntax is pseudo established,
> but I'm beggining to become a bit jaded about all the
> built in properties were building. What about good ol'
> aliases?
>
> sub hidden (str $name, int $force := $override) {...}
I'm not keen on it becaus
Erik Steven Harrison wrote:
> Is it just me or is the 'is' property syntax a little
> too intuitive? Seems like everywhere I turn, the
> proposed syntax to solve a problem is to apply a
> property.
That's because most of the problems we're discussing are solved
by changing the semantics of
> sub hidden (str $name, int $force is aka($override))
>{ ... }
I know that the property syntax is pseudo established,
but I'm beggining to become a bit jaded about all the
built in properties were building. What about good ol'
aliases?
sub hidden (str $name, int $force := $override)
{
Somewhere, in another thread . . .
Dr. Claw wrote . . .
>> sub hidden (str $name, int $force is aka($override))
>>{ ... }
>
>Yeah, that's what I meant.
Is it just me or is the 'is' property syntax a little
too intuitive? Seems like everywhere I turn, the
proposed syntax to solve a problem
[EMAIL PROTECTED] wrote:
>> sub hidden (str $name, int $force, int $override is aka($force))
>> { ... }
>
>
> Would the following be simpler...?
>
> sub hidden (str $name, int $force is aka($override))
>{ ... }
Yeah, that's what I meant.
Sorry. I've travelled 14,000 miles and given 93
From: Damian Conway [EMAIL PROTECTED]
> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
>{ ... }
How does this method affect the non-parameter-based calling scheme? It
looks like it is possible to
From: Damian Conway [EMAIL PROTECTED]
> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
>{ ... }
Would the following be simpler...?
sub hidden (str $name, int $force is aka($override))
{ ... }
Peter Behroozi wrote:
> Has anyone considered a syntax for allowing subroutines to have many
> different names for the same argument?
If it were allowed, it would probably be done via properties instead:
sub hidden (str $name, int $force, int $override is aka($force)) { ... }
Damian
From: Peter Behroozi [EMAIL PROTECTED]
> Has anyone considered a syntax for allowing
> subroutines to have many different names for
> the same argument? For example, in CGI.pm, many
> methods support the "-override" parameter but
> can also accept the alias of "-force":
Yes. See the thread start
Hello All,
Has anyone considered a syntax for allowing subroutines to have many
different names for the same argument? For example, in CGI.pm, many
methods support the "-override" parameter but can also accept the alias
of "-force":
$cgi->hidden(-name => "a", -override => 1); #same as
$cgi->hi
27 matches
Mail list logo
