Matt Calabrese writes:
Also, as a side note, the templates key_type and value_type are great, however, can I suggest possibly changing value_type to mapped_type? The reason being to be consistent with the STL, since an STL container's value_type for a map would be the pair, while the mapped_type is what would be the mapped type of the associative sequence. This isn't as big of a deal, but if you are concerned with consistency, it might be a good idea to change (or at least add a mapped_type template and leave value_type so that it doesn't break old code).
I agree that 'mapped_type' would be a better name here, but then I find the whole '_type' convention for these two suboptimal: 1. It makes it sound like the templates are trivial metafuntions for the corresponding STL typedefs, which is not the case. 2. Pretty much everything in MPL is a type; the '_type' suffix doesn't add any semantic value to the names besides contributing to #1, and, I believe, is somewhat misleading: "What do you mean, key _type_? It's key's value!". So, if we were to rename/introduce synonyms for these, I'd rather keep 'key'/'value' terminology and replace '_type' with something more explicit/less ambiguous, e.g.: +-------------------------------+---------------------------------------------------------------+ | ``key_part<s,x>::type`` | The key part of the element ``x`` that would be | | | used to identify ``x`` in ``s``; see |key_part|. | +-------------------------------+---------------------------------------------------------------+ | ``value_part<s,x>::type`` | The value part of the element ``x`` that would be | | | used for ``x`` in ``s``; see |value_part|. | +-------------------------------+---------------------------------------------------------------+ -- Aleksey Gurtovoy MetaCommunications Engineering