Ordered Hashes -- more thoughts
Steve Tolkin
user visible bug. At a minimum it should support the special case of
delete that is supported by the Perl each() operator.
Details: This Week in Perl 6, May 25, 2005-May 31, 2005
http://www.perl.com/pub/a/2005/06/p6pdigest/20050602.html has a brief
discussion of Ordered Hashes with this link
http://groups-beta.google.com/group/perl.perl6.internals/browse_frm/thre
ad/86466b906c8e6e10/24a935c5c2c71aa8#24a935c5c2c71aa8 where Dan Sugalski
says: "I'd just pitch an exception if code deletes an entry ..."
Perhaps this is OK, because this code is intended for internal use only.
But people like to reuse code, and if anyone writes an ordered hash
module on top of this code it will have a bug. There are already two
ordered hash modules, and at one time they both had a bug involving
delete. On March 10, 2004 I sent email about this to the authors of
Tie::LLHash (Ken Williams) and Tie::IxHash (Gurusamy Sarathy) and also
to perl...@listserv.ActiveState.com. (Ken then fixed the bug in
Tie::LLHash.) Because that email does not seem to be archived anywhere.
I am including the most relevant part here:
There is a bug in Tie::IxHash and also Tie::LLHash.
The bug is caused by using a delete in a loop .
# This *IS* a bug because
# http://www.perldoc.com/perl5.8.0/pod/func/each.html says:
# It is always safe to delete the item most recently returned by
# each(), which means that the following code will work:
# while (($key, $value) = each %hash) {
# print $key, "\n";
# delete $hash{$key}; # This is safe
# }
P.S. I am sending this as email to perl6-internals. Should I instead
post to the news group? That is harder for me, but doable if it is the
right thing.
.
Hopefully helpfully yours,
Steve
--
Steve Tolkin Steve . Tolkin at FMR dot COM 617-563-0516
Fidelity Investments 82 Devonshire St. V4D Boston MA 02109
There is nothing so practical as a good theory. Comments are by me,
not Fidelity Investments, its subsidiaries or affiliates.
Leopold Toetsch
> Summary: An ordered hash that does not support deletes could cause a
> user visible bug. At a minimum it should support the special case of
> delete that is supported by the Perl each() operator.
The proposed ordered hash ist mostly used for Parrot internals. If a
user visible OrderedHash PMC is there, it will have some restrictions -
or not - WRT delete or indexed-only inserts.
A Perl Hash is still something different and doesn't have these
restrictions.
leo
Bob Rogers
Date: Wed, 8 Jun 2005 16:22:35 -0400
At 4:05 PM -0400 6/8/05, Tolkin, Steve wrote:
>. . . Dan Sugalski says: "I'd just pitch an exception if code
>deletes an entry ..."
>
>Perhaps this is OK, because this code is intended for internal use
>only. But people like to reuse code, and if anyone writes an
>ordered hash module on top of this code it will have a bug.
Which is why it ought not get reused.
The whole point of the original ordered hash was to support lexical
pads as fast as possible while still allowing by-name lookup for
introspective code. Doing anything that compromises fast array-based
lookup would be ill-advised for that. If it makes sublclassing tough,
well... subclassing continuations is likely going to be problematic
too, but that's fine . . .
Maybe the problem lies in thinking of this as an "ordered hash" when it
really functions as a "keyed array." People expect to be able to delete
hash entries, but not always array entries. So a name change might make
inability to delete less of an issue.
-- Bob Rogers
http://rgrjr.dyndns.org/