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