[Apologies to Aaron Sherman, who gets this twice due to my
dunderheadedness]
Aaron Sherman <[EMAIL PROTECTED]> writes:
[...]
> Also, another though:
>
> sub foo($a = 1, $b, $c) { ... }
>
> In C++ at least, I think this is an error. However, it seems to me that
> in Perl it could be interpreted to be equivalent to:
>
> sub foo($a = 1, $b = undef, $c = undef) { ... }
>
> Which, again, allows us to clean up the common case.
Not really. The problem (and the reason C++ doesn't allow this) is
that
sub foo($a=1, $b, $c=3) { ... }
is ambiguous: While foo(2) sets $a=1, $b=2, $c=3, it's impossible to
say what foo(4,5) should do.
Hence the C++ rule: all optional matches at the end.
One could also imagine a rule saying all optional matches occur
right-to-left, no matter where they are; this would be very confusing,
though. It's also a bad idea, software-engineering-wise. Say I start
off with
sub bar($a, $b=2, $c, $d=4) { ... }
So bar(11,12,13) matches 11,12,13 -> $a,$b,$c, and bar(1,3) matches
1,3 -> $a,$c. All seems well, until I decide that since anyway $c is
usually 3, I should change the signature and make $c optional too:
sub bar($a, $b=2, $c=3, $d=4) { ... }
Now bar(11,12,13) continues to match 11,12,13 -> $a,$b,$c, but
bar(1,3) matches 1,3 -> $a,$b! So the semantics of old code changes,
silently.
The only ways I can see for optional arguments are:
* all at the end
* at most one
* named arguments
Note that the first 2 *can* be done together (but I'm not sure that
would be a good idea, either). And we already have 3, kinda, by
passing a hash of arguments.
--
Ariel Scolnicov |http://3w.compugen.co.il/~ariels
Compugen Ltd. |[EMAIL PROTECTED]
72 Pinhas Rosen St. |Tel: +972-3-7658117 "fast, good, and cheap;
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 pick any two!"
