in reply to Re^3: 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'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

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