On Mon, Apr 19, 2004 at 01:44:53PM -0400, John Siracusa wrote:
: On 4/19/04 1:30 PM, Larry Wall wrote:
: > On Mon, Apr 19, 2004 at 01:14:57PM -0400, John Siracusa wrote:
: > : I know we are running out of special characters, but I really, really think
: > : that required named parameters are a natural fit for many common APIs. A12
: > : has reinforced that belief. Save me, Dami-Wan Wallnobi, you're my only
: > : hope...
: >
: > Well, actually, we saved you last summer when we decided to make +
: > mean that the parameter must be named.
:
: ...named and required, or named and optional? IOW, is this all true?
:
: sub foo(+$a, +$b) { ... }
:
: foo(); # compile-time error!
: foo(1, 2); # compile-time error!
: foo(a => 1, 2); # compile-time error!
: foo(a => 1); # compile-time error!
:
: foo(a => 5, b => 7); # ok
: foo(b => 1, a => 2); # ok
Well, no, we're still stuck at run-time validation of that. In the case
of methods you can't really do anything else anyway, generally speaking.
For subs, we could make the compiler pay attention to something in the
declaration:
sub foo(+$a is req, +$b is req) { ... }
sub foo(+$a = fail, +$b = fail) { ... }
But I still don't think it rates a strange character of its own.
Possibly there's something going on with multi subs and invocants.
I'm not sure what 6.0.0 will make of a declaration like:
multi sub foo(+$a, +$b: +$c) { ... }
since we've told the Parrot people they don't have to worry about
anything but positional parameters for 6.0.0.
But none of this has much bearing on BUILD routines, which are shielded
from positional semantics anyway by the fact that .bless() doesn't
take any extra positional parameters.
Larry
