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 C<is 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 C<is 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
