Re^3: MCE::OrdHash naming Push and Unshift methods supporting merging and reordering

Replies are listed 'Best First'.
Re^4: MCE::OrdHash naming Push and Unshift methods supporting merging and reordering by marioroy (Prior) on Aug 19, 2015 at 09:11 UTC
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]
Re^4: MCE::OrdHash naming Push and Unshift methods supporting merging and reordering by marioroy (Prior) on Aug 19, 2015 at 17:30 UTC
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]
Re^4: MCE::OrdHash naming Push and Unshift methods supporting merging and reordering (Solved) by marioroy (Prior) on Aug 19, 2015 at 20:56 UTC
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]
Re^5: MCE::OrdHash naming Push and Unshift methods supporting merging and reordering by GrandFather (Saint) on Aug 21, 2015 at 08:32 UTC
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]
Re^6: MCE::OrdHash naming Push and Unshift methods supporting merging and reordering (Solved) by marioroy (Prior) on Aug 21, 2015 at 13:16 UTC
I appreciate the enlightenment given and like PushNew and UnshiftNew a lot. Thank you.	[reply]