RE: Perl 6 modules plan

------_=_NextPart_001_01C124D1.2D59CFF0
Content-Type: text/plain;
	charset="iso-8859-1"

From: Graham Barr [mailto:[email protected]]
> On Mon, Aug 13, 2001 at 04:38:43PM -0700, Nathan Wiger wrote:
> > And allow flexible calling styles. For example, you might say:
> > 
> >    # import args() for argument validation
> >    use Module::Interface qw/args/;
> > 
> >    sub my_func (@) {
> >        my %args = args({ positional => [qw/name email 
> >        phone/] }, @_);
> >    }
> > 
> > Which would allow you to call your function two different ways:
> > 
> >    my_func($name, $email, $phone);
> >    my_func(name => $name, email => $email, phone => $phone);
> 
> This is the king of thing that CGI does, and IMO is exactly 
> what we don't want.
> 
> 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.

TOW of Perl?

What about RFC128? http://dev.perl.org/rfc/128.html

Subroutines: Extend subroutine contexts to
include name parameters and lazy arguments 

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 don't have the experience to make well balanced judgements in language and
library design, but I would hope that RFC128 style function signatures would
be required. I'm sure modules which prioritize on performance would chose
ordered parameter lists, but higher level ones would benefit from a heavier
reliance on named parameters. And if people'd RTFM on RFC128, perhaps
calling style confusion would be minimal.



------_=_NextPart_001_01C124D1.2D59CFF0--