Re: Argument aliasing for subs
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
deviation from standard behaviour.
This is the argument that would win me over to the property syntax.
Self documenting code is an admirable goal. But I wonder about our
overuse of 'is'.
Think of it as punctuation. As a necessary alternative to the poor
overworked colon.
The performance issues of a hash that lives with every variable aside,
They're not really relevant with Cis, since it's compile-time in effect.
it all looks the same to me. And I like different things to look different.
A fair point. My counterargument is that you're looking at the wrong bit.
Cis aka(...), Cis named(...), Cis constant, etc all look very similar,
structurally. But so do C$obj.foo(), C$obj.bar(), and C$obj.baz().
Yet we cope quite well with the OO syntax, because we look at the different
method names, not the shared dot introducer.
Properties have a great deal in common with methods, and so it really
should be surprising that they're invoked in a structurally similar manner.
Think s/dot/is/.
I find:
sub hidden (str $name, int $force is aka($override)) {...}
*much* more readable, since I can read it in English.
Yeah . . . except I want at least single quotes around that darn $override.
Required singles even. Having it be context sensitive to the type of property
is WAY to subtle for me. And if $override is a reference I'd like that to DWIM (
though I understand that I may be the only person for which that behavior is
intuitive).
And what happens with double quotes - a symref? Ack!
Then why don't you want single quotes around the C$name and C$force?
After all, they're not being evaluated there either.
The Cis aka would be a form of auxiliary declaration, so it's quite as
reasonable not to put annoying quotes around it. It just means that the
parameter list of the property would be declared with one of Larry's
postulated Cis parsed(/Perl.variable/) properties.
If $force is aka(override) is going to be a compile time error, then why can't we
just $force is aka(override) and just carry the typing over.
So you can't stand a bare declarative variable, but you'd accept a bareword??? ;-)
The rason I'd do it the way I've suggested is precisely so that if someone's flawed
mental model causes them to write:
$force is aka(override)
that *logical* bug in their thinking is detected and flagged.
And if it's not a compile time error then what in Knuth's name
Now, now, no need to invoke deities! ;-)
oh never mind - my head just exploded.
Hang in there. If these mixed number Cakas were allowed then I'd suggest
the semantics be that they indicate that *either* a scalar or array is
acceptable in the corresponding argument slot. The scalar variant of the
parameter would be bound to a scalar argument, or to a reference to an array
argument. The array variant of the parameter would be bound to an array
argument, or it's zeroth element bound to a scalar argument.
-Erik
Damian
PS - Ha! My name above Damian's :-)
Letting me get the last word, eh? Very kind of you. ;-)
Damian
Re: Argument aliasing for subs
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 a trusted source
return 255 but undef; # i.e. system() returns
# undefined 255 on failure
return $cached_for{$arg} but Cached
//= compute_for($arg); # memoize return value
# but mark when from cache
$result = heuristic($data) but Estimated
unless %known{$data}; # indicate when value is a guess
my $temp is Units('Celsius')# indicate units of variable
= 273 but Units('Kelvin'); # indicate units of value
# (maybe autoconverted?)
return $val but Error(-1..+2); # indicate error bars
$data = $text but Encrypted($public_key);
# unusable without private key
$days = 29 but From(My.line); # record source of
# improbable value
$days = 29 but Reason(Leap year);
# so-called active comment...
# documents why improbable value
# used but can also be retrieved
# programmatically
$name = Damian but We_better_call_ya(Bruce);
# indicate correct Australian
# pronunciation ;-)
Damian
Re: Argument aliasing for subs
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 though it is, result in a compile time error? If my perception was incorrect, what was the logic behind the decision that compile time properties must be part of a predefined set, but runtime may be arbitrarily defined? Or is there another explanation that I'm missing? I think my paradigm is shifting without a clutch. Steve _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: Argument aliasing for subs
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 would my $var is true, meaningless though it is, result in a compile time error? Because it's lower-case, but not a standard built-in property. If my perception was incorrect, what was the logic behind the decision that compile time properties must be part of a predefined set, There is no such requirement. Indeed, there will almost certainly be possible to define an is True property yourself (note the capitalization). And it could quite easily cause any value assigned to it to be ascribed Cbut true. Damian
Re: Argument aliasing for subs
--
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 that you're looking at the wrong bit.
A fair counterargument (a new programming game -
badmitton!)
At this point I originally had a long reply stating my
feelings. In the course of writing it and trying to
anticiplate Damian's counter counter counter arguments
the reply grew and grew until I realized I had changed
sides. But I'll assemble what thoughts were worth
salvaging into a different post and see where they go,
and get Damian off of the CC list :-).
Hang in there. If these mixed number Cakas were allowed then I'd suggest
the semantics be that they indicate that *either* a scalar or array is
acceptable in the corresponding argument slot. The scalar variant of the
parameter would be bound to a scalar argument, or to a reference to an array
argument. The array variant of the parameter would be bound to an array
argument, or it's zeroth element bound to a scalar argument.
I think that my problem here lies that I want to treat
a property as either a lvalue or a subroutine call,
and my brain keeps screaming Watch out for variable
interpolation!. I've been bitten by that enough in my
early module writing days that the fear comes quickly.
What I need (and I hope I'm not alone, or with too
much company) is to know exactly what the is does
here. What kind argument is it taking? Value, name, or
reference? Once I pin that down, the whole thing
should be clear.
-Erik
Damian
PS - Ha! My name above Damian's :-)
Letting me get the last word, eh? Very kind of you. ;-)
Touche ('cept with an accent on the e there). Maybe were fencing, not playing
badmitton.
-Erik
Damian
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
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 idea of the Cis named property is that it *changes* the external key by
which you specify the corresponding parameter when using named parameters.
That is:
sub foo ($bar is named('baz')) {
print $bar; # Okay
print $baz; # Error (not a real param)
}
foo(bar=1);# Error (not known by this name externally)
foo(baz=1);# Okay
Whereas the is aka property *adds* an alias for the corresponding parameter,
when using named parameters. That is:
sub foo ($bar is aka($baz)) {
print $bar; # Okay
print $baz; # Okay (Just another name for $bar)
}
foo(bar=1);# Okay
foo(baz=1);# Okay (Just another key meaning bar=1 )
So, should it really be
int $force is aka($override)
Yes.
or
int $force is aka('override')
No, not the way I intended it.
I much prefer the latter because: a) it unquestionably marks 'override'
as a label for $force,
It's not meant to be. That's what Cis named would be for.
b) the subroutine author is likely to use either
$force or $override and not both,
Possibly. But if it's truly an alias, they should be able to use both.
c) it gives meaning to things like $force is aka(override)
True. Though it would be more useful in reverse:
sub foo (bar is aka($baz)) {
# now bar is an array
# and $baz is an array ref
}
Then again, if you have good reasons for the other syntax, I would be
more than happy to hear those as well.
Then I hope this made you happy. ;-)
Damian
Re: Argument aliasing for subs
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.
_
Join the worlds largest e-mail service with MSN Hotmail.
http://www.hotmail.com
Re: Argument aliasing for subs
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 to output false.
Why? I believe that, whatever you set $var to, you have marked the
variable as constantly true in booleans.
Where this gets weird is that someone might write:
sub foo {
my $result is true;
# (do stuff setting result)
if $success {
return $result;
} else {
return undef;
}
}
Thinking that the initial is true will cause the test
if foo()
will always be true if the sub succeeded, even if $result was zero. But I
don't think that's how it works, since the Creturn will pass the
*value*, which has not been tagged with but true, not the variable,
which has been tagged with is true. So the test will fail when $result
was zero. (Unless there's something going on where the is true property
confers a property to the value, which I suppose is possible, but weird.)
My guess is that
return $foo but true;
will become a common piece of Perl 6 idiom.
Trey
Re: Argument aliasing for subs
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 values that are true or false. That is why I want to understand if is sets properties of variables or values. _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
Re: Argument aliasing for subs
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 $var=0;
SC if ($var) {print true}
SC else {print false}
SC I would expect it to output false.
it won't even compile so i don't expect output. :)
this wasn't clear enough when it was discuss. you can't set data
properties on a variable and vice versa. 'is' sets variable props and
'but' sets data props. runtime stuff will usually check data props
(maybe readonly which is a variable prop would be checked then
too). compile time stuff will deal with variable props.
OO will be a different story as all the my Dog $spot threads have
shown. until that apocalypse i won't venture how OO will deal with props.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
RE: Argument aliasing for subs
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 but string(one) but tainted;
FWIW, though, I think we can probably get away with 'is' only and
tagging of properties:
#XXX are classes properties? Will they look something like
this?
class string is property('run') {
method INIT($targ: $strval) {
$targ.prop{string}=$strval;
}
method operator:_($targ:) {
return $targ.prop{string};
}
}
class aka is property('compile') {
method INIT($me: $targ: *@names) {
# $foo.prop{name} is the FIRST name given to
that, i.e., the first
# variable it was bound to.
my $targname=$targ.prop{name}.substr(1,
$targ.prop{name}.length-1);
# $targ.prop{scope} is the stash of the FIRST
name given to it.
my $scope = $targ.prop{scope};
# $scope.num is a hash mapping names to
positions.
my $num = $scope.num{$targname};
for @names - $name {
$scope.num{$name} = $num;
}
}
}
class named is property('compile') {
method INIT($me: $targ: *@names) {
my $targname=$targ.prop{name}.substr(1,
$targ.prop{name}.length-1);
my $scope = $targ.prop{scope};
my $num = $scope.num{$targname};
$scope.num.delete($targname);
for @names - $name {
$scope.num{$name} = $num;
}
}
}
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator.
--Damian Conway
Re: Argument aliasing for subs
--
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 $force := $override) {...}
I'm not keen on it because it will be hard to explain
(or detect) the difference between that and:
sub hidden (str $name, int $force //= $override) {...}
Just found this hidden in my inbox. I didn't think anyone was paying attention ;-).
I think that the difference can be swept under the table in a handwavy sort of manner
by pointing out that these subroutine declarations shouldn't be pointing to globals or
widely scoped lexicals like that. But this all brings me back to the question of
lexical leaking. Are $name and $force lexical to the sub? I know that we are trying to
avoid lexical scopes leaking into each other, but I honestly can't figure out how that
rules and these argument declarations interact. Someone care to explain?
What I most like about the Cis syntax is (like methods in
OO Perl), it associates a meaningful *name* with each
deviation from standard behaviour.
This is the argument that would win me over to the property syntax. Self documenting
code is an admirable goal. But I wonder about our overuse of 'is'. The performance
issues of a hash that lives with every variable aside, it all looks the same to me.
And I like different things to look different. In a related note, I'm always confused
by whether or not we look at the value of the variable or it's name. See below . . .
I find:
sub hidden (str $name, int $force is aka($override)) {...}
*much* more readable, since I can read it in English.
Yeah . . . except I want at least single quotes around that darn $override. Required
singles even. Having it be context sensitive to the type of property is WAY to subtle
for me. And if $override is a reference I'd like that to DWIM (though I understand
that I may be the only person for which that behavior is intuitive). And what happens
with double quotes - a symref? Ack!
If $force is aka(override) is going to be a compile time error, then why can't we
just $force is aka(override) and just carry the typing over. And if it's not a compile
time error then what in Knuth's name does it . . . . oh never mind - my head just
exploaded.
-Erik
Damian
PS - Ha! My name above Damian's :-)
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
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'
aliases?
sub hidden (str $name, int $force := $override) {...}
I'm not keen on it because it will be hard to explain
(or detect) the difference between that and:
sub hidden (str $name, int $force //= $override) {...}
Just found this hidden in my inbox. I didn't think anyone was paying
attention ;-).
I think that the difference can be swept under the table in a
handwavy sort of manner by pointing out that these subroutine
declarations shouldn't be pointing to globals or widely scoped
lexicals like that. But this all brings me back to the question of
lexical leaking. Are $name and $force lexical to the sub? I know that
we are trying to avoid lexical scopes leaking into each other, but I
honestly can't figure out how that rules and these argument
declarations interact. Someone care to explain?
What I most like about the Cis syntax is (like methods in
OO Perl), it associates a meaningful *name* with each
deviation from standard behaviour.
This is the argument that would win me over to the property syntax.
Self documenting code is an admirable goal. But I wonder about our
overuse of 'is'. The performance issues of a hash that lives with
every variable aside, it all looks the same to me. And I like
different things to look different. In a related note, I'm always
confused by whether or not we look at the value of the variable or
it's name. See below . . .
I find:
sub hidden (str $name, int $force is aka($override)) {...}
*much* more readable, since I can read it in English.
Yeah . . . except I want at least single quotes around that darn
$override. Required singles even. Having it be context sensitive to
the type of property is WAY to subtle for me. And if $override is a
reference I'd like that to DWIM (though I understand that I may be
the only person for which that behavior is intuitive). And what
happens with double quotes - a symref? Ack!
If $force is aka(override) is going to be a compile time error, then
why can't we just $force is aka(override) and just carry the typing
over. And if it's not a compile time error then what in Knuth's name
does it . . . . oh never mind - my head just exploaded.
-Erik
Damian
PS - Ha! My name above Damian's :-)
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
-- 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 we're discussing are solved by changing the semantics of a variable, subroutine, or class in some way, and Cis properties are the way to do that in Perl 6. And is the is/but distinction still around? Oh, yes. Thanks goodness. Since but's proposal I've not seen any use of it, and the distinction between a compile time and run time property was somewhat hazy to me anyway, so I can't be sure that it's dead or just of rare use. Of rare use (nice turn of phrase, BTW). Thanks. 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? -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
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 e-mail service with MSN Hotmail. http://www.hotmail.com
Re: Argument aliasing for subs
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 by Larry or Damian: http:[EMAIL PROTECTED]/msg07604.html Btw, I've created a tiny url for using google groups to search for posts by Larry or Damian in perl 6 lists since early May 2002 (google doesn't have archives prior to then :). http://tinyurl.com/1ce0 (Some posts similar to those shown will have been filtered out; you can fix that by going to the last page and clicking the 'repeat the search with the omitted results included' link). -- ralph
Re: Argument aliasing for subs
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 a variable, subroutine, or class in some way, and Cis properties are the way to do that in Perl 6. And is the is/but distinction still around? Oh, yes. Since but's proposal I've not seen any use of it, and the distinction between a compile time and run time property was somewhat hazy to me anyway, so I can't be sure that it's dead or just of rare use. Of rare use (nice turn of phrase, BTW). Cis is about changing the way a variable or sub operates, Cbut is about changing what a value means. We'll see much greater use of Cbut when people start developing new algorithms and programming idioms with Perl 6. Damian
Re: Argument aliasing for subs
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 will be hard to explain
(or detect) the difference between that and:
sub hidden (str $name, int $force //= $override) {...}
What I most like about the Cis syntax is (like methods in
OO Perl), it associates a meaningful *name* with each
deviation from standard behaviour.
I find:
sub hidden (str $name, int $force is aka($override)) {...}
*much* more readable, since I can read it in English.
Damian
Re: Argument aliasing for subs
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
int $force is aka($override)
or
int $force is aka('override')
?
I much prefer the latter because: a) it unquestionably marks 'override'
as a label for $force, b) the subroutine author is likely to use either
$force or $override and not both, c) it gives meaning to things like
$force is aka(override) because aliases would not have to be known at
compile-time.
Then again, if you have good reasons for the other syntax, I would be
more than happy to hear those as well.
Peter Behroozi
RE: Argument aliasing for subs
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
http:[EMAIL PROTECTED]/msg09551.html . The
end result was that Damian liked the idea and leans towards a syntax like
this:
sub load_data (
$filename_tainted is named('filename'),
$version_input is named('version','ver') //= 1)
{...}
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Argument aliasing for subs
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
Re: Argument aliasing for subs
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))
{ ... }
Damian's statement says to me that there is an argument named $force, and
another argument named $override which is also known as $force... that
sounds conflicting. The revised statement simply says that there's an
argument named $force and it is also known as $override.
BTW, the aka thing is cool. It could be complementary to is named:
# can't use force_tainted as argument:
sub hidden (int $force_tainted is named($force))
# can use force_tainted as argument:
sub hidden (int $force_tainted is aka($force))
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Argument aliasing for subs
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 use three arguments in the call to
hidden(). While this doesn't matter for this case, it might if another
named argument was tacked on to the end, like this:
sub hidden (str $name, int $force, int $override is aka($force),
int $pretty_print);
print hidden('name',1,1); #-- What does this do?
I think that the slight modification of Damian's original solution is
the best:
sub hidden (str $name, int $force is aka('override')) { ... }
Then there is no question that override is Just Another Name for
force (eliminating weird things like $force is aka(@override)), the
problem of argument order in normal sub calls goes away, and there is a
happy minimum of extra syntax.
By the way, thanks for pointing out the original discussion; I haven't
been on the list long enough to have known that it existed.
Peter Behroozi
Re: Argument aliasing for subs
[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
presentations in the last 18 days. [Note to self: no more
posting whilst semi-conscious!!!]
%-)
BTW, the aka thing is cool. It could be complementary to is named:
# can't use force_tainted as argument:
sub hidden (int $force_tainted is named($force))
# can use force_tainted as argument:
sub hidden (int $force_tainted is aka($force))
Yes, that was the idea. :-)
Damian
Re: Argument aliasing for subs
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 to apply a
property. And is the is/but distinction still around?
Since but's proposal I've not seen any use of it, and
the distinction between a compile time and run time
property was somewhat hazy to me anyway, so I can't be
sure that it's dead or just of rare use.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Argument aliasing for subs
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)
{ . . .}
While less verbose, it's actually more legible to me,
in that the prototype (we still calling it that?)
get's less visual clutter.
In a related note, even if the 'is aka($am, $are,
$also_known_as) = 'Electric Mayhem')' syntax get's
establsihed will the alising trick still work? Or are
we stepping on the Perl 6 rule against leaking lexical
scopes?
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
