Greetings all,

I have been working on MCE::OrdHash, a sharable ordered hash module for use with MCE::Shared. These things will be included with MCE 1.7 when released. MCE::OrdHash is 100% compatible with Tie::IxHash. It overlays a modified tombstone deletion seen in Hash::Ordered. It supports both OO and Tie. The OO interface is faster, but provides auto-tie on-demand when hash-like dereferencing is requested. This is done via an autoload directive.

The Push and Unshift methods in MCE::OrdHash merges for existing keys to remain compatible with Tie::IxHash. It adds two methods when reorder is desired. The method names are PushRo and UnshiftRo. Reorder means having to delete an existing key prior to inserting.

I seek for the opinion of other monks on the naming of PushRo and UnshiftRo. Should I name these something else?

Thank you, Mario

If interested, I benchmarked against Hash::Ordered and Tie::IxHash. I have dropped MCE::Hash::Indexed (OI) and keeping MCE::Hash::Ordered (OT) which is now MCE::OrdHash.

  • Comment on MCE::OrdHash naming Push and Unshift methods supporting merging and reordering

Replies are listed 'Best First'.
Re: MCE::OrdHash naming Push and Unshift methods supporting merging and reordering
by GrandFather (Saint) on Aug 19, 2015 at 07:18 UTC

    I'd be inclined to use PushNew and UnshiftNew because you are adding a new key or replacing an old one. The reorder is kinda incidental to the fact that you want the new key to be the authoritative one.

    Premature optimization is the root of all job security
[reply]

      I like your suggestion and will rename the methods to PushNew and UnshiftNew. Thank you GrandFather.

      These are the last bits that boggles my mind. The Keys and Values methods in Tie::IxHash take indices as arguments. MCE::OrdHash does the same for compatibility and includes methods for receiving keys. Arguments are optional for all of them. The Pairs method return key/value pairs.

      ## Keys (indices), Values (indices), Pairs (indices)
## keys (keys   ), values (keys   ), pairs (keys   )

      [download]

      Are these okay? The Keys and Values methods cannot change to not break compatibility with Tie::IxHash.

      Thank you in advance for guidance on this.

      Sincerely, Mario

[reply]
[d/l]

        The change in case is too subtle for my taste. I'd go for KeysKeyed, ValuesKeyed and PairsKeyed. A bunch more typing, but oh so much clearer.

        Premature optimization is the root of all job security
[reply]

Back to Meditations