> =head1 ABSTRACT
>
> This RFC proposes that subroutine argument context specifiers be
> extended in several ways, including allowing parameters to be typed and
> named, and that a syntax be provided for binding arguments to named
> parameters.
I agree with most, if not all, of this RFC.
> =head3 Named arguments
>
> It is further proposed that arguments may be passed by name, and that
> named arguments may be passed in any order.
>
> An argument would be associated with a named parameter by prefixing it
> with a standard Perl label (i.e. an identifier-colon sequence). For example:
>
> @mapped = doublemap(args: @list, mapsub: ^a+^b);
I persoanlly would prefer '=>' to be used here instead of ':', which
makes it look more like the current CGI and Tk modules, but can live
with ':'.
A few questions:
- Do we envisage something similar for method calls?
This would, of course, shift a large part of the burden of this scheme
to run-time.
- Do we support creating a named parameter list at run-time?
Right now I am a heavy user of the hash-like notation and I've got quite
a few subroutines with variable named arguments. My subroutines now
have to do the validity checking themselves. If we have this nice new
scheme, I'd be very happy for it to support dynamically created, but
still checked, named arguments.
Once again, this shifts a portion of the work to run-time.
- Would we also want to support this one step deeper?
For instance, with the DBI 'connect' call, you can specify options like
this:
$dbh = DBI->connect('dbi:Sybase:server=foo', 'name', 'pwd',
{ RaiseError => 1, AutoCommit => 0 });
It might be nice (but maybe also unwise) to check the options in the
fourth argument...
Hildo
