Front page | perl.perl5.porters |
Postings from December 2019
Re: Named Parameters
From:
Tony Cook
Date:
December 17, 2019 00:07
Subject:
Re: Named Parameters
Message ID:
20191217000641.GQ6429@mars.tony.develop-help.com
On Mon, Dec 16, 2019 at 11:23:43AM -0500, Rocco Caputo wrote:
> On Dec 16, 2019, at 06:54, hv@crypt.org wrote:
> >
> > Dave Mitchell <davem@iabyn.com> wrote:
> > :On Fri, Nov 29, 2019 at 04:44:24PM +0000, hv@crypt.org wrote:
> > :> Dave Mitchell <davem@iabyn.com> wrote:
> > :> :Note that for duplicate arguments, only the right-most value is likely to
> > :> :evaluated; for example foo(name => $tied1, name => $tied2) would likely
> > :> :only call (tied $tied2)->FETCH(), although we don't guarantee this.
> > :>
> > :> Such a guarantee would be useful for the foo(%defaults, %options) idiom.
> > :
> > :That's not obvious to me, Could you expand upon it?
> >
> > %defaults could include values that are expensive to evaluate (eg via tie);
> > a guarantee that they would not be evaluated unnecessarily would make that
> > a reasonable thing to do. Failing such a guarantee one would probably choose
> > instead to write extra code at each calling site to check manually whether
> > the default is needed.
>
> Would this guarantee also apply to %foo = (%defaults, %options)
>
> If not, how would the difference be explained?
The assignment is well defined to copy the values, it has historically
done so and changing it may break existing code.
for foo(%default, %args) the function call itself doesn't copy the
values, so even now a careful implementation could scan @_ for names
and only evaluate the later values in @_.
Tony