develooper Front page | perl.perl5.porters | Postings from December 2019

Re: Query Parameters

Thread Previous | Thread Next
From:
hv
Date:
December 3, 2019 14:46
Subject:
Re: Query Parameters
Message ID:
201912031438.xB3EcNP00739@crypt.org
Dave Mitchell <davem@iabyn.com> wrote:
:On Fri, Nov 29, 2019 at 04:51:15PM +0000, hv@crypt.org wrote:
:> Dave Mitchell <davem@iabyn.com> wrote:
:> :=head2 Hash query parameter
:> :
:> :This is most useful in the presence of named parameters. [...]
:> :
:> :A hash query parameter can appear anywhere in the signature, including in
:> :amongst positional parameters, but in that case it is an error unless it
:> :is an even number of positional parameters before any first named
:> :parameter:
:> :
:> :    sub foo($p1, ?%query, $p2, $p3, :$n1, :$n2) { ... }  # ok
:> :    sub foo($p1, $p2, ?%query, $p3, :$n1, :$n2) { ... }  # compile-time err
:> 
:> Maybe most useful, but not only useful in the presence of named parameters.
:> As such, it needs to allow for optional positionals. I think for this case
:> it should be defined explicitly _not_ to check parity, and silently include
:> a trailing undef if needed.
:
:So you mean something like:
:
:    sub foo(?%all, $p1, $p2 = 0)
:
:?

Yes.

:
:My current intent would be:
:
:In the absence of any named params (or trailing hash slurpy), no runtime
:parity check is done on the args.
:
:If called as foo("a"), then %all becomes ("a", undef).

Good, that's what I would have hoped.

:What about 
:
:    sub foo(?%all, $p1, $p2, $p3 = 0)
:
:should that be a compile-time error or wok with an implicit undef 4th arg?

I think it should get an implicit undef if parity requires it: called with
two arguments, %all should have just one pair, and not an additional
(undef => undef) pair. I.e. it should behave the same as C< %all = @_ >.

Hugo

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About