Front page | perl.perl5.porters |
Postings from December 2019
Re: Named Parameters
From:
Dave Mitchell
Date:
December 16, 2019 12:23
Subject:
Re: Named Parameters
Message ID:
20191216122224.GD3620@iabyn.com
On Mon, Dec 02, 2019 at 06:41:10PM -0500, Dan Book wrote:
> On Mon, Dec 2, 2019 at 6:37 PM Tony Cook <tony@develop-help.com> wrote:
>
> > On Thu, Nov 28, 2019 at 05:01:42PM +0000, Dave Mitchell wrote:
> > > The ordering of parameter types within a signature would be extended to
> > be:
> > >
> > > 1) zero or more mandatory positional parameters, followed by
> > > 2) zero or more optional positional parameters, followed by
> > > 3) zero or more mandatory named parameters, followed by
> > > 4) zero or more optional named parameters, followed by
> > > 5) zero or one slurpy array or hash
> > >
> > > Except that would be a compile-time error to have both (2) and (3).
> > >
> > > (3) and (4) are new. Note that here isn't any semantic need for any
> > > optional named parameters to always follow all mandatory named
> > parameters,
> > > but including that restriction doesn't prevent you doing anything (as far
> > > as I can see), provides consistency with positional parameters, and
> > > potentially allows better optimisations.
> >
> > I'd prefer to be able to mix mandatory and optional named parameters,
> > a function might take one mandatory parameter that's necessary for the
> > function, and an optional parameter with a reasonable default that
> > describes how to interpret that parameter.
> >
> > Allowing those to remain together in the signature improves the
> > readability of the signature.
> >
> > For example, pixels and type in
> >
> >
> > https://metacpan.org/pod/distribution/Imager/lib/Imager/Draw.pod#setscanline
>
>
> I agree. This restriction isn't necessary, doesn't have any clear benefit,
> and means existing calls would very likely have to be adjusted when such a
> signature is applied in a codebase.
Unless I've misunderstood you, I don't think this is the case.
This issue is purely whether
sub foo (:$required1, :$required2, :$opt1 = $def1, :$opt2 = $def2)
should be allowed to be written as the functionally equivalent
sub foo (:$required1, :$opt1 = $def1, :$required2, :$opt2 = $def2)
Neither the caller of the function, nor the body of the function would be
affected by such a re-ordering.
In reply to Tony, the main reason I proposed this restriction is that I
wanted to able to
1) guarantee parameters are always processed in strict L-R order;
2) all calls out to default expression code are handled at the *end* of
signature processing. This means that all arg processing can (eventually)
be handled by a single OP_SIGNATURE op which optimises away several
OP_ARGELEM ops; at the end, pp_signature returns the address of the first
default op expression needing processing.
To allow mandatory and optional named args to be mixed means either
the L-R order guarantee order would be broken, or all signature processing
after the first optional named parameter would (probably) have to be
unoptimised.
But I can see the visual appeal of allowing them to be mixed.
--
Overhead, without any fuss, the stars were going out.
-- Arthur C Clarke