Re: [boost] [mpl] broken count and at metafunctions

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2005-08-31 06:55:38

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