At 04:03 PM 4/11/2002 -0400, Aaron Sherman wrote:
>On Thu, 2002-04-11 at 14:34, Larry Wall wrote:
> > Miko O'Sullivan writes:
>
> > : Well, I had been hoping to appeal to the mathematical mindset of the
> list,
> > : but there is a second reason for = in addition to / /=: it's simpler to
> > : understand. I just think that the potential Perl hackers will
> understand =
> > : right away but will have to spin a lot of cycles to get / /=, and will
> > : meanwhile be wondering why not just =. I'm hoping to point out that = is
> > : both logically precise AND more marketable.
> >
> > Leaving marketability aside for the moment, I don't buy the argument
> > that it's a feature for the user to be able to pass an undef past the
> > default. The primary purpose of the default is to guarantee the
> > semantics of the function, not to make life easier for the caller.
> > If that also happens, it's a nice side effect.
>
>Hmmm... I have to disagree with you there.
>
>Consider this bit of Perl5 which I've done in various forms:
>
> sub nukeuser {
> my $user = shift;
> my $pwf = shift;
> $pwf = '/etc/passwd' unless defined $pwf;
> my $backup = @_ ? shift @_ : "$pwf.bak";
> my $do_backup = defined($backup);
> ...
> }
>
>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? :)
>We're not just makeing life easier for the caller. What we're doing is
>extracting as much information from the arguments as possible (just as
>many Perl functions do). With //=, there's simply some data thrown away.
>
>In Perl6, this might be:
>
> sub nukeuser ($user, $pwf //= 'passwd', $backup = "$pwf.bak") {
> my $do_backup = defined $backup;
> ...
> }
>
>[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.
Else your function prototypes become a language of their own.
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.
-Melvin
