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. :-(


Reply via email to