From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
> On Tue, Aug 14, 2001 at 09:55:37AM -0500, Garrett Goebel wrote:
> > > There should be ONE calling style for each sub/method.
> > > Allowing this _will_ cause different people to use different
> > > calling styles and also possible confusion.
> >
> > It gives us a cleaner way to mix and match order dependant and named
> > parameter lists. Not to mention the potential for
> > optimization hints, parameter type checking and constraints
> > (no auto-vivication), lazy evaluation, etc.
>
> I think you misunderstand. This isn't named parameters vs prototyped
> parameters vs args as list. The problem is the idea that functions
> should accept *multiple styles by default* which the proposed
> Module::Interface does.
I don't think I'm misunderstanding. -There's a first!
Why do we need a "Module::Interface" when RFC128 covers all this ground and
more? It provides for required, optional, and type-checking of positional
and named parameters. (and more).
> foo($this, $that, $whatever);
>
> foo( this => $this,
> that => $that,
> whatever => $whatever
> );
Or per RFC128,
sub foo (INTEGER $this, STRING $that, FLOAT $whatever) {
printf "TMT %d %s, just my \$%.2f\n", $this, $that, $whatever
}
foo(1, 'way', 0.02);
foo(whatever: 0.02, this: 1, that: 'way');
> Saying that most core functions should be callable both ways is
> overkill.
I didn't say that.
What I did say is that I hoped RFC128 style function signatures would be
required. That doesn't mean you have to use named parameters. Just that "a"
function signature would be required.
Graham stated that multiple calling styles are confusing... And I'd agree
that Module::Interface and existing modules like CGI.pm could easily lead to
confusion. But I don't see how that applies to the syntax proposed in
RFC128.
I suppose whether or not it is overkill to allow for both, will depend on
the overhead involved in how it is implemented. According to RFC128, named
parameters can be optionally specified. Either way, positional parameters
will always work. So per Perl6 w/ RFC128, it'll be positional parameters or
positional-and-named parameters.
> This is what CGI.pm does (for historical reasons, I
> believe, and not by design). It's unnecessarily confusing and
> requires a not insignificant amount of life-support to make work.
CGI.pm does a lot of things for the convenience of its users. Like Tk and
File::Spec, CGI's functions can be called procedurally or as methods. But
lets not go there.
If RFC128 flies... I don't see why this would be confusing or require any
significant life-support. It'll be a language detail instead of an
implementation nightmare. Just because it is an "issue" now doesn't mean it
has to be one in Perl6.
> Having Module::Interface around to do this sort of thing when desired
> is nice, but please don't cannonize it.
No. I've kludged together similar things when I thought I need it. -But
RFC128 isn't a kludge. Though I'd so hoped that it would create world peace
;)
