p5pRT
commented
14 years ago From @xdg
This patch updates all functions that operate directly on array or hash containers to also accept references to arrays or hashes:
push $arrayref\, @stuff; unshift $arrayref\, @stuff; pop $arrayref; shift $arrayref; splice $arrayref\, 0\, 2; keys $hashref; # or $arrayref values $hashref # or $arrayref ($k\,$v) = each $hashref # or $arrayref
Because this patch is a substantial new feature and will likely merit some discussion\, I have organized this commit message as follows:
* Summary of benefits * Summary of the patch * Rationale
_Summary of benefits_
As I see it\, the primary benefit is visually de-cluttering common operations in situations where the context (acting on a "container") is clear.
As a side effect of the implementation of this change\, calling keys/values directly on a reference gives roughly a 75%+ performance boost compared to Perl 5.13.6.
keys $hashref; # much faster than "keys %$hashref"
(Prior to 5.12\, keys %$hashref was similarly fast\, but the optimization was lost when keys/values added support for arrays)
I suspect that\, if accepted\, similar optimizations might be possible for push/pop/etc ops.
_Summary of the patch_
For push/pop/shift/unshift/splice ops\, I added a new 'ck_push' check routine. If the child op is not an array or array dereference\, the child op is wrapped in an array dereference.
For keys/values/each\, I added three new opcodes to handle the case where the argument is not a hash or array (or explicit dereference of them). All three ops are handled by one function that dereferences the argument (including any magic) and then dispatches to the corresponding hash or array implementation of the original function. If the argument is not a hash or array\, a runtime error is thrown.
For keys/values/each\, when overloaded dereferencing is present\, the overloaded dereference is used instead of dereferencing the underlying reftype. Warnings are issued about assumptions made in the following three ambiguous cases:
(a) If both %{} and @{} overloading exists\, %{} is used (b) If %{} overloading exists on a blessed arrayref\, %{} is used (c) If @{} overloading exists on a blessed hashref\, @{} is used
The new warnings have been added to perldiag.pod with an explanation.
For all affected built-ins\, the prototype has been changed to use the new 'single-term' prototype '+'. E.g. for push\, the prototype is "+@".
Documentation and tests are included.
_Rationale_
Perl is a language that give great respect to the idea of context. I use that term below in the linguistic sense in which the pattern of usage guides interpretation (rather than in the programming sense of "scalar" or "list" context).
There are a number of built-in functions that act directly on "containers" (i.e. hashes and arrays) and that pass their first argument by reference rather than flattening the container into a list. E.g. because of the linguistic context of a function like "push" in "push @array\, @list"\, perl passes @array by reference.
In various venues and forums\, I've heard people express the desire for perl do the "obvious thing" when providing a reference directly to such functions that act on containers. E.g. "push $arrayref\, @list". The linguistic context provided by "push" is exactly the same -- it is clear that the goal is to act on the container itself.
In contrast\, one can't reach the same conclusion about\, for example\, "foo($_) for $arrayref". The "for" doesn't give any clear linguistic context for whether $arrayref is intended to be flattened or used as a single element list aliased to $_.
Therefore\, this patch allows perl to use a reference to a container directly for built in functions only where the linguistic context *already* allows perl to pass the container by reference instead of flattening it.
In discussing this patch or variations of it on email and IRC\, I've heard lots of praise for the idea. The justifications I've seen are various combinations of "easier to read"\, "less to type" and/or "less annoying".
Those who dislike the idea of this patch generally seem to be of the opinion that dereferencing "should be explicit" or that the patch "isn't necessary" (which may just be a variation of the first objection).
To the first objection\, I say that this is a matter of style and reasonable people already disagree on the "best" Perl style. This patch delivers a desired feature to those who do want it without interfering with the ability of others to explicitly dereference everything as a matter of personal (or corporate) style.
I dismiss the second objection out of hand. By its very nature as a community-driven project\, nothing in the development of Perl is "necessary" and the very definition of "necessary" will vary from person to person. In this case\, the work is desired and it is already done.
As mentioned in the summary\, the changes to keys/values/each to accept references happened to lead to a significant performance improvement\, recovering some of what was lost when 5.12 changed the implementation to allow keys/values/each to act on arrays in the first place.
The changes to push/pop/etc did not require the same degree of changes (i.e. I didn't add new opcodes for them) and I kept the patch as simple as possible. However\, if the patch is accepted\, I suspect that the same technique that allows optimization of "keys $hashref" could be explored later to optimize "push $arrayref\, @list" over "push @$arrayref\, @list".
MANIFEST | 1 + doop.c | 5 +- embed.h | 4 + op.c | 85 +++++++++++-- opcode.h | 21 +++- opnames.h | 5 +- pod/perldelta.pod | 26 ++++ pod/perldiag.pod | 16 +++ pod/perlfunc.pod | 75 +++++++++-- pod/perlsub.pod | 10 +- pp.c | 81 ++++++++++++- pp.sym | 4 + proto.h | 9 ++ regen/opcode.pl | 12 ++- t/op/cproto.t | 16 ++-- t/op/push.t | 39 ++++++- t/op/smartkve.t | 361 +++++++++++++++++++++++++++++++++++++++++++++++++++++ t/op/splice.t | 7 +- t/op/unshift.t | 36 +++++- 19 files changed\, 757 insertions(+)\, 56 deletions(-) create mode 100644 t/op/smartkve.t
Migrated from rt.perl.org#78656 (status was 'resolved')
Searchable as RT78656$