Dov Wasserman writes:
> Long-time lurker, first time poster. Dittos, kudos, etc.
Welcome aboard.
> Since in the rest of Perl 6, the '~' operator involves string
> representation, perhaps the standard +$foo marker should really be ~$foo:
> i.e., $foo only has a (string) name, not a numeric position. Thus ~$foo
> would mean exactly what +$foo currently means: $foo may only be passed by
> name, and it is optional.
Hmm... I'm quite sure that I like ~ better than + for mnemonic purposes.
> Declaring a parameter to be named-only would now require a different syntax.
> For your parametric perusal pleasure:
>
> 1. sub foo($req1, ?$opt1, ~$optNamedOnly, ~$reqNamedOnly is req) {...};
> 2. sub foo($req1, ?$opt1, ~$optNamedOnly, +$reqNamedOnly) {...};
> 3. sub foo($req1, ?$opt1, ~?$optNamedOnly, ~$reqNamedOnly) {...};
> 4. sub foo($req1, ?$opt1, $optNamedOnly is named, $reqNamedOnly is named
> is req) {...};
I'm for option 1.
The reason I don't think that named-only and required should get huffman
privilidges is simply because of the rarity of use. We've had arguments
that they'll be used often, but I don't think they will. The main
argument is: what if I want to add a required parameter but not break
compatibility. Well, if you've added a required parameter, you've just
broken compatibility, named or not.
Although I can see wanting a fully documentary interface, that's really
the caller's decision. Perl enjoys leaving the decisions to the caller:
thus C<use fatal>. It's a philosophy that I strongly agree with.
A newer point that was brought up is that with the new implicit *%_ on
methods, required named parameters seem more viable. But the reason the
implicit *%_ was introduced is so that derived methods could add
parameters without violating the Liskov substitution principle. Adding
a required named parameter would do just that.
On the other hand, Perl's always been a purist in impurity. There are
more subtle reasons for wanting to add a required named parameter.
Adding the => syntax to a method call, while the parameter isn't
formally named, can be a useful language building idiom. That's why I
support the C<is req[uired]?> trait. But making a special character
sequence for it will end up confusing people, being mishuffmanized.
Luke
