Front page | perl.perl5.porters |
Postings from December 2019
Re: Query Parameters
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
December 3, 2019 13:20
Subject:
Re: Query Parameters
Message ID:
20191203131945.GU3620@iabyn.com
On Fri, Nov 29, 2019 at 04:51:15PM +0000, hv@crypt.org wrote:
> Dave Mitchell <davem@iabyn.com> wrote:
> :=head2 Array query parameter
> [...]
> :Unlike the other query types, this one always examines the raw argument
> :list, (i.e. before being sorted for named parameters). Because of this,
> :an array query parameter is forbidden from appearing anywhere to the right
> :of any named parameter.
>
> Is the transition point only the actual declaration of a named parameter?
> It would also be plausible to say that in sub foo(?$have_name, :$name)
> the boolean query already introduces the start of processing for named
> parameters, and therefore that it should be not permitted to write
> sub foo(?$have_name, ?@all, :$name).
I think it could be argued either way. The raw and sorted arg lists
are identical up until the first named arg is consumed, so
(?$have_name, ?@all, :$name) has (or can have) a well-defined meaning.
>
> :=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)
?
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).
What about
sub foo(?%all, $p1, $p2, $p3 = 0)
should that be a compile-time error or wok with an implicit undef 4th arg?
--
Dave's first rule of Opera:
If something needs saying, say it: don't warble it.
Thread Previous
|
Thread Next