On 2/19/07, Gottlob Frege wrote:

I was just concerned that you were putting too much meaning into std::pair (in general, not just in the context of maps). The members never really should have been called 'first/second' (implying order or lack of symmetry or any other meaning). I think it was just such a generic concept ('pair') that it was hard to name the members - maybe they should have just been called 'foo' and 'bar' to avoid any meaning. So do you feel first/second has too much meaning, or that it has too much meaning and history in the context of map? ie if you are saying that even if they were named foo/bar you would still want something different so as to emphasize the difference from std::map, I can understand that.

As you said, first/second has a lot of meaning in the context of the standard mapping framework. You have express it very clear.

...

...

- I think 'relation' is too generic a word to abscond.

...

From the dictionary: "A logical or natural association between two or more things"

It is mostly the 'or more' that bothers me. And that 'left/right' is more specific than 'relation'. left <-> right is a very specific relation (called 'opposing directions' or something like that) as is first <-> second "before/after", as is "between" - a relation between 3 things. 'relation' is a term that covers all of these, and is thus too generic. Do you want a term for a generic 2 item relation or a specific 2 item relation? What are the properties of your specific relation? 'balanced'? 'invertable'?

'symmetric'... 'bidirectional'... This discussion will surely take place later on the review. If other people think that is better to rename this new beast, I have no problem to change it. The important thing is to maintain the left/right notation.

In the end, it also hinges on the namespace issue. 'bimap::relation' is, to me, a very specific relation (the relation inherent in a bimap). 'boost::relation' or 'using bimap; ... relation' is polluting with a too generic term.

relation will be inside boost::bimap namespace, not in boost.

...

...

- the nature of typing code forces order - ie note that bimap is different than bimap (although philosophically the same).

(Side Note: Using tags they are exactly the same.)

The same to the compiler? and to boost::mpl? Cool. And as it should be.

Yes, from the tutorial: struct id {}; // Tag for the identification number struct name {}; // Tag for the name of the person typedef bimap< tagged< int , id >, tagged< multiset_of<string>, name >

People;

People people; // ... map_by<id>(people)[28928546] = "Gray Simpson"; map_by<name>(people).insert( value_type_by("Marta Smith",30215692) ); cout << get<id>(*people.begin()); You can write the instantiation as typedef bimap< tagged< multiset_of<string>, name >, tagged< int , id >

People;

and everything will just work. Best Regards Matias

hello,

...

1) The new notation left/right used instead of first/second.

I am wondering if left/right will scale well. Isn't it reasonable to anticipate that the library could evolve into trimap, quadrimap and so on? Left/center/right could work for trimap but it becomes harder to find names for quadrimaps? Maybe going with one/two/three/four... instead would be better. Regards JCR

On 2/20/07, Jean-Christophe Roux wrote:

Hello,

...

1) The new notation left/right used instead of first/second.

I am wondering if left/right will scale well. Isn't it reasonable to anticipate that the library could evolve into trimap, quadrimap and so on? Left/center/right could work for trimap but it becomes harder to find names for quadrimaps? Maybe going with one/two instead would be better.

The framework is about *bidirectional* mapping. This restriction allows us to build a very intuitive interface that extend the stl mapping framework. A bimap is a very frequent beast, so it is worth to have a special design for it. Trimaps and quadrimaps are less frequent. With trimaps you have to make a lot of changes to the interface. The operator[] will lost their meaning. trimap tm; tm.one[x] = ?? And the most important thing is that when you are viewing one of the sides you can not provide the symmetric behaviour of the actual framework bimap bm; bm.left // --> map : X first, Y second bm.right // --> map : Y first, X second For a general N-map framework the best approach is to use Boost.MultiIndex. Best Regards Matias Capeletto