> > 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 ':'.
I think => is difficult, since using it would potentially break an
enormous amount of existing code than relies on its comma-like properties.
The more I play with "name:", the happier I am with it (and with its
connotations of Perl labels).
Give it some time and see if it grows on you too ;-)
> 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.
I had been loathe to propose that methods respect their parameter lists,
precisely because they would have to do so strictly at run-time, and we
hardly need anything slowing down method dispatch! Of course, if
Dan tells me he can do it fast enough... :-)
I haven't been worried because I have privileged access to the inside
of my head (well, more of a curse than a privilege, really...) and so
I know that the forthcoming multiple dispatch RFC will solve the problem
in the (even more) general case -- although multimethod calls will look
like subroutine calls, not method calls.
Hence I had proposed to leave methods free of the overheads of parameter
lists.
> - Do we support creating a named parameter list at run-time?
As long as we support eval "string", we sure do! :-)
Curiously, I was just discussing this off-line with David L. Nicol,
and suggesting that it might be possible to use the qs{...} idea
from RFC 75 to do just that:
my $sub = sub (qs{$param_list}) { body };
> - 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...
I considered this and decided against it.
Of course, once I get my RFC of pre- and post-conditions for subroutines,
youll be able to do the checking there to:
a) keep it out of the main subroutine code, and
b) inherit it in derived classes.
Damian
