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 Cis syntax is (like methods in
OO Perl), it associates a meaningful *name* with each
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 is
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, meaningless
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, why
--
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 counterargument is
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.
The
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.
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 expect it
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 reference
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 time error.
SC
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, 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 (str $name, int
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: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 the problems
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 largest
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, especially posts
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 because it
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 be
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 starting at
[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 hours of
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 is
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)
{ .
22 matches
Mail list logo