On Fri, 2002-04-12 at 00:37, Melvin Smith wrote:
> At 04:03 PM 4/11/2002 -0400, Aaron Sherman wrote:
> >Notice that we have two different types of defaulting here. The second
> >argument is the file to work on, and we set it to a reasonable default
> >if it is undefined for whatever reason. However, the third argument is
> >sensitive to undef vs no parameter. In the case of not getting a third
> >arguement, a reasonable default is set. If an argument is given, but it
> >is undef, no backup will be performed.
>
> So we have undef and reallyundef? :)
Yes, just as with any array. We always have an exists() vs defined(). We
also have a length.
An argument list has a length and each element either exists or does
not. An undefined parameter still exists, of course. Is this not basic
Perl?
> >[I don't know if you can use a parameter to default another parameter.
> >It would be nice, but I can see why you wouldn't.]
> >
> >Without an "=" operator here, you would need to add another argument to
> >flag doing backups or not (not really the Perl Tao) or you would have to
> >do the argument processing manually, which sort of defeats the whole
> >point.
>
> I would typically handle this with overloading the function instead.
> Its definitely easier for the reader to understand that way, in my opinion.
Ok, let's take my example and try to do it with overloading:
sub nukeuser ($user,$pwfile //= $pwdfl) {...}
sub nukeuser ($user,$pwfile //= $pwdfl, $backup) {...}
Question, are you proposing that this is valid? Would I need a second
//= on the $backup? Which version would nukeuser('ajs') call? Which one
would nukeuser(backup => $x, user => $y) call (I *think* that one is
obvious to me, but I don't see how it's obvious to the compiler).
You're proposing a whole lot more coding for the user than:
sub nukeuser ($user,$pwfile//=$pwdfl,$backup="$pwfile.bak") {...}
Which, seems to also be easier on the eye, at least to me. Granted, the
//= looks a little funky, but that's the syntax we already had. I'm just
proposing the simpler one be added.
> Else your function prototypes become a language of their own.
Having two operators is hardly "a language of their own" if it is, then
having the one operator is half a language? ;-)
> I wish we would stick to simple semantics, allow overloading, allow
> a single operator for a default argument, and follow the C++ style of
> ambiguity resolution.
The C++ style of ambiguity resolution does not involve passing parameter
pairs, list explosion, etc. These are all features that Perl6 will have
from the gate, so I just don't see how Perl6 can have the same approach
as C++.
What's more, in C++,
void foo(const char* a="stuff"){ ... }
foo(NULL);
will pass NULL, not "stuff". We're proposing a syntax which is incapable
of that distinction. :-(