Front page | perl.perl5.porters |
Postings from December 2019
Re: Named Parameters
From:
Dan Book
Date:
December 2, 2019 23:41
Subject:
Re: Named Parameters
Message ID:
CABMkAVUkDT52d7zz=eTe+gCeR9fSmERaz057onpZsvbVYmq2rg@mail.gmail.com
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.
-Dan