Front page | perl.perl5.porters |
Postings from December 2015
What should the semantics of @_ be for a sub that has a signature?
Currently as well as populating the signature args, we populate @_.
Since manipulating @_ on sub entry and exit is quite expensive, it
would make sense to not populate it.
If we don't populate, then the two main things to be decided are:
1. What (if anything) should @_ be and contain? Normally each sub
has its own arg array, and on entry to the sub it does the equivalent
of
local *_ = $my_private_arg_array;
1a. The most efficient thing to do is to leave @_ untouched as the
parent's arg array, using the existing &foo; sub call mechanism;
e.g. the following prints "same as parent":
sub f { $farr = \@_; &g; }
sub g { $garr = \@_; print "same as parent\n" if $farr == $garr; }
f(1,2);
while it doesn't if you change f to:
sub f { $farr = \@_; g(); }
So a signature sub would populate its parameter vars but leave @_ unchanged;
this would print "(a,b)=(3,4); @_=(1 2)":
sub f { g(3,4); }
sub g ($a,$b) { print "(a,b)=($a,$b); \@_=(@_)\n" }
f(1,2);
1b. Another possibility, which is much less efficient but more programmer
friendly, would be to give each sub an empty, read-only AV which will
croak if you try to modify it.
1c. Slightly more efficient than 1b, but still much less efficient than
1a, would be for all signature subs to share a single empty, readonly AV,
rather than being one per sub. This would alter the semantics of \@_ etc.
2. What, if anything should replace @_?
If a signature sub no longer has access to @_, what does it lose?
The most obvious thing is a count of the number of args: so you can't
for example tell whether a parameter var got assigned a default value
or not.
I can't think of any examples of the top of my head why you'd need access
to the elements of @_ as well as it's length.
Of course a sub can always fall back to a signature of sub (@a) {}
and treat @a as @_, but that way you lose all the added checking, default
handling, and possible efficiency of signatures.
If it's just scalar(@_) that's required, then what syntax should be used to
access this value? I feel that it should be something in the signature
itself that indicates you want this value, so that it's not unnecessarily
set for the subs which don't require it.
If we can't reach an early consensus on this, then I propose that we at
least document that @_ is subject to change in signature subs.
PS - reviving my OP_SIGNATURE work is the next big thing on my list
once I've finished the context/scope stuff I've been working on.
--
More than any other time in history, mankind faces a crossroads. One path
leads to despair and utter hopelessness. The other, to total extinction.
Let us pray we have the wisdom to choose correctly.
-- Woody Allen
Thread Next