[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]
Re: exists $foo[7] and delete $foo[7]
In <200001131718.JAA13655@activestate.com>, Gurusamy Sarathy writes:
:I fixed the two problems by adding a avhv_delete_ent(), and suddenly
:realized you could do the exists() and delete() operations now on
:pseudo-hashes but not on real arrays (even though pseudo-hashes are
:little more than real arrays). If these operations were extended
:to arrays, several things become simultaneously possible:
:
: * consistency in how the delete() and exists() operators work
: across hashes, arrays, and pseudo-hashes
: * cleaner internal implementation of pseudo-hashes
: * delete(), in particular, affords the ability to reclaim compact
: storage in arrays, which the efficiency hounds will appreciate
: * semantically, arrays are little more than efficient ordered
: hashes; I therefore see delete() and exists() not working on
: arrays as an arbitrary limit, and this gets rid of that limit
:
:So I decided to should extend exists() and delete() to cover arrays
:as well.
:
:I should note that I'm not particularly attached to this going in for
:5.6. Maybe we should take a vote on whether we want to keep it or
:not. I think I've already cast my vote by putting it in. :-)
I feel that deeply knowledgeable perl programmers will gain from this,
and the rest will lose. The current inconsistency between arrays and
hashes benefits beginners, since it gives them an error if they try
to use delete() or exists() on an array.
If it is intended that avhv's play a much greater role in perl code
at all levels in the future, then even beginners will need to
understand them: in that case, this change should go in as soon as
possible, and any other hash operations that cannot currently be
performed on arrays should also be added.
If, as I suspect, avhv's are destined to remain occasionally useful
esoterica, I do not feel that the gain justifies the cost: in that
case, it might be more appropriate to require a special directive
before permitting any use of hash operations on arrays.
There has been some discussion of the use of attributes as compiler
hints: it might give a cleaner language for all if the pseudohash
became a different type of internal storage for a hash, prompted by
such a compiler hint, with no visible changes to the mechanisms for
access of either hash or array. This implies that you would not be
able to see the pseudohash-as-array at all at the Perl level, except
perhaps by asking Devel::Peek about it. Similarly, you could hint
that an array was expected to be sparse, and the compiler could
choose to store that internally as a hash.
Hugo
- Follow-Ups from:
-
Jarkko Hietaniemi <jhi@iki.fi>
- References to:
-
Gurusamy Sarathy <gsar@activestate.com>
[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]