Front page | perl.perl5.porters |
Postings from December 2021
On Tue, Dec 07, 2021 at 06:02:23PM +0000, Paul "LeoNerd" Evans wrote:
> I think a lot of that isn't even necessary though. A variant of my
> no-snails branch which I haven't yet committed or pushed, very slightly
> relaxes the rules and allows a use of @_ as an rvalue in scalar
> context, purely to allow the code to determine the argument count.
I HATE that suggestion!
For one thing, @_ is still a real variable, containing the args of the
sub's (grand**N)parent, and will generally be a different size than the
proposed value of scalar(@_).
E.g. (assuming for the sake of demonstration that @_ is accessible to
print at run time):
sub sig ($a,$b) { print "@_"; print scalar @_ }
sub plain { sig(qw(d e)); }
plain(qw(a b c));
outputs: (a b c 2), i.e. @_ contains 3 values but scalar(@_) returns 2.
Second, using the arg count as a way of determining whether a default arg
was passed etc, is awkward, ugly and error-prone for all but the simplest
subs:
sub foo ($self, $base, $action, $flags, $result, $x, $y = 0, $z = 0) {
my @point = ($x);
push @point, $y if @_ > 6;
push @point, $z if @_ > 7;
$self->do_point(@point);
....
}
whereas the query params proposal allows:
sub foo ($self, $base, $action, $flags, $result,
?@point,
$x, $y = 0, $z = 0)
{
$self->do_point(@point);
....
}
(The example above is where you want to call point($x) rather than
point($x,0,0) if the caller didn't supply y and z).
A perhaps more common example would be the equivalent for:
sub foo {
my $self = shift;
my ($foo, $bar,...) = @_;
do_something($foo, $bar,...);
$self->SUPER::foo(@_) };
}
which with query parameters becomes
sub foo($self, ?@args, $foo, $bar,...) {
do_something($foo, $bar,...);
$self->SUPER::foo(@_) };
}
PS - my intention is that the args will just be left on the stack,
@_ / padsv[0] will never be populated, and OP_ARG* get their values
directly from the stack.
--
Justice is when you get what you deserve.
Law is when you get what you pay for.
Thread Previous
|
Thread Next