However, I wonder if a derived class might want to know the order in which they were added, some day.
Originally I figured that the access method to get the worklist, used strictly internally also for all access to it, could be overridden to return a reference to a tied hash that also keeps an order. It turns out that this actually is a little more complex, because I would also need to provide a method to reset the list. So it's not as cute as I thought.
So I'm thinking why not just provide the order already? I could use such an ordered hash class from the getgo, but I don't see one as a standard module and I want to use only modules that come with the normal Perl installation. Also there might be a performance hit with that.
Or, I can keep a list for the order as well as the hash for the index, explicitly. So, how do I provide access to that?
Storing the ordering as a specially-named member of the hash seems awkward, and less than elegant from a module interface point of view.
Two separate named methods would be clear.
Having multiple return values from a single method would be neater, but would that be awkward too?
I'm open to suggestions and design musings.
—John
In reply to Hashes made to order by John M. Dlugosz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |