At 4:05 PM -0400 6/8/05, Tolkin, Steve wrote:
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.
Details: This Week in Perl 6, May 25, 2005-May 31, 2005
<http://www.perl.com/pub/a/2005/06/p6pdigest/20050602.html>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/thread/86466b906c8e6e10/24a935c5c2c71aa8#24a935c5c2c71aa8>http://groups-beta.google.com/group/perl.perl6.internals/browse_frm/thread/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.
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.
Reuse is good but everything doesn't need to be reusable. Special
purpose data structures are just fine too.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
