in reply to Re: MCE::OrdHash naming Push and Unshift methods supporting merging and reordering
in thread MCE::OrdHash naming Push and Unshift methods supporting merging and reordering

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

  • Comment on Re^2: MCE::OrdHash naming Push and Unshift methods supporting merging and reordering
  • Download Code

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

    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]

      The new names are definitely clearer. The methods PushRo, UnshiftRo, keys, values, and pairs will change to PushNew, UnshiftNew, KeysKeyed, ValuesKeyed, and PairsKeyed respectively.

      I will optimize Keys(indices), Values(indices), and Pairs(indices) as these may be used more often without arguments due to shorter names. Am thinking that KeysKeyed is unnecessary now and can be removed from the API.

      Thank you, Mario

[reply]

      I'm thankful for the suggestions on KeysKeyed, ValuesKeyed, and PairsKeyed. After playing around with this, am realizing that is rather difficult actually. The reason is that keys, values, and pairs are also used by MCE::Shared.

      Another option is naming them as KeysInd( indices ), ValuesInd( indices ), and PairsInd( indices ) along with Keys( keys ), Values( keys ), and Pairs( keys ). This will break API compatibility with Tie::IxHash and fine with that.

      MCE::Shared::Hash by itself (in MCE::Shared::Client) is not ordered. Thus, is without indices behind the scene. Having the shorter names is nice in that sense. At the very least, am wanting for Keys, Values, and Pairs to match between MCE::OrdHash and MCE::Shared::Hash even if it means breaking API compatibility with Tie::IxHash.

      In summary, I agree with GrandFather and now dislike Keys / keys, Values / values, Pairs / pairs with the change in case being too subtle for passing indices or keys. But, KeysKeyed, ValuesKeyed, and PairsKeys seems unnecessary for MCE::Shared::Hash which is without indices.

      After reviewing everything, the least common denominator is MCE::Shared::Hash. Keys, Values, and Pairs take keys as arguments for not having indices. So, will do the same in MCE::OrdHash and have have KeysInd, ValuesInd, and PairsInd take indices.

      Does this sound like a good plan? This will break 100% compatibility with Tie::IxHash, but am wanting to consider MCE::Shared::Hash which is not ordered (without indices).

      Thank you, Mario

[reply]

      This is done and committed into trunk. All methods names begin with an upper case letter for consistency. Keys, Values, and Pairs are compatible with the same in MCE::Shared::Hash which lacks indices for not being ordered.

      ## KeysInd (indices), ValuesInd (indices), PairsInd (indices)
## Keys    (keys   ), Values    (keys   ), Pairs    (keys   )

## Pop, Push    (merge  ), Shift, Unshift    (merge  ), Splice
##      PushNew (reorder),        UnshiftNew (reorder),

      [download]

      Thus, MCE::OrdHash is mostly compatible with Tie::IxHash except for Keys and Values which take keys as arguments, not indices. KeysInd and ValuesInd come included receiving indices for compatibility.

      Thank you, Mario

[reply]
[d/l]

        That all looks fine and consistent to me. I don't see Tie::IxHash as a particularly compelling driver, although I concede that using something common as a template is better than just inventing stuff. However, consistency in a name space (i.e. with MCE::Shared::Hash) is better still.

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

In Section Meditations