Fwd: [bimap] Review of the Bimap library begins today Feb 15
---------- Forwarded message ---------- From: Matias Capeletto <matias.capeletto@gmail.com> Date: Feb 18, 2007 2:39 PM Subject: Re: [Boost-users] [bimap] Review of the Bimap library begins today Feb 15 To: boost@lists.boost.org On 2/18/07, Gottlob Frege <gottlobfrege@gmail.com> wrote:
On 2/15/07, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Hello everyone,
The review of the proposed Boost Bimap library written by Matias Capeletto starts today (February 15th, 2007) and ends after 10 days (February 25, 2007).
Hi Gottlob,
So far: A: namespace: ---------------------
from the 'One Minute Tutorial':
That is more or less all that is needed to start using the bidirectional map. The following two lines must also be added:
#include <boost/bimap/bimap.hpp> using namespace bimap;
2 points: - I prefer not to use 'using'. I know I don't have to, but I don't like that the docs imply that I do.
Ok, the "must" in the docs is maybe to strong. I can reword that.
more importantly: - is it going to be in 'bimap' or in 'boost'?
We have to put everything inside a namespace, I do not want to pollute the boost namespace.
B: 'relation' ----------------
I think I understand the philosophical reasoning for preferring 'left/right' over 'first/second', and thus the impetuous for creating 'relation'. However...
Two issues to talk about here. 1) The new notation left/right used instead of first/second. 2) A new name for 'relation'. We have to introduce the new notation. In the context of maps, the notation first/second is used in places where the first element has different meaning than the second one. left/right is symmetrical and implies that both sides are at the same level, that there is no special side.This is the key point to grasp. This is explained here: http://cablemodem.fibertel.com.ar/mcape/boost/libs/bimap/boost_bimap/the_tut...
- I think 'relation' is too generic a word to abscond.
From the dictionary: "A logical or natural association between two or more things" I like 'relation'. But we can talk about other names.
- how about: - couple - duo
The thing is that these words are very similar to "pair" and the idea is to mark the difference.
- or probably just 'bipair'
That was my original choice. 'relation' sounds better to me but let see what other people think about this.
- or maybe even consider that std::pair, although not perfect, might make things easier:
Using left/right instead of first/second is an important design decision. Here is where things start mixing up.
- it can be used in other algorithms
The new notation is used in very different contexts. The algorithms written for first/second has no sense in the contexts where left/right are used. If you want to use algorithms that works with map/pair notation you have to pass one of the side views to it.
- it is already well known
That is true and in the context of maps it have a very established meaning different from what we want to express with left/right. This is a point for the new notation.
- the nature of typing code forces order - ie note that bimap<X, Y> is different than bimap<Y, X> (although philosophically the same).
(Side Note: Using tags they are exactly the same.)
Even with 'left/right' you still have order - left corresponds to the *first* type listed in the bimap, 'right' corresponds to the *second* type passed in. Or is it bimap<Right, Left>? I don't think so.
You still have order. The important thing to understand is that we are not looking to eliminate that order. We want to express that the two things are equally important.
But other than that, so far so good. Looks like something I'd use. And the docs are snazzy.
Thanks! Matias
On 2/18/07, Matias Capeletto <matias.capeletto@gmail.com> wrote:
more importantly: - is it going to be in 'bimap' or in 'boost'?
We have to put everything inside a namespace, I do not want to pollute the boost namespace.
If it is excepted into boost, then I expect it to 'pollute' boost's namespace (at least somewhat). But I think the boost developers probably have a better understanding of where it should fit in than I do. If it is in its own namespace 'bimap', I expect it will at least be boost::bimap. (ie boost::bimap::bimap<X,Y>)
Two issues to talk about here.
1) The new notation left/right used instead of first/second. 2) A new name for 'relation'.
We have to introduce the new notation. In the context of maps, the notation first/second is used in places where the first element has different meaning than the second one. left/right is symmetrical and implies that both sides are at the same level, that there is no special side.This is the key point to grasp. This is explained here: http://cablemodem.fibertel.com.ar/mcape/boost/libs/bimap/boost_bimap/the_tut...
As I said originally, I think I understand the philosophy behind it. Stressing not only that it is 'philosophically different' but that it is *important* to be different from map (ie since bimap is so similar it is important to emphasize the differences) is maybe something I should keep in mind. So I can agree with that. 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.
- 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'? 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.
I like 'relation'. But we can talk about other names.
- or probably just 'bipair'
That was my original choice. 'relation' sounds better to me but let see what other people think about this.
- or maybe even consider that std::pair, although not perfect, might make things easier:
- it is already well known
That is true and in the context of maps it have a very established meaning different from what we want to express with left/right. This is a point for the new notation.
I'm starting to see that this is the main reasoning for the naming. OK.
- the nature of typing code forces order - ie note that bimap<X, Y> is different than bimap<Y, X> (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. - Tony
On 2/19/07, Gottlob Frege <gottlobfrege@gmail.com> 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<X, Y> is different than bimap<Y, X> (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<name,People>("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
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.
std::pair members really are asymmetric, so the names 'first' and 'second' are certainly in place. Think operator< ...
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
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. JCR
On 2/20/07, Jean-Christophe Roux <jcxxr@yahoo.com> 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<X,Y,Z> 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<X,Y> bm; bm.left // --> map<X,Y> : X first, Y second bm.right // --> map<Y,X> : Y first, X second For a general N-map framework the best approach is to use Boost.MultiIndex. Best Regards Matias Capeletto
participants (5)
-
Gottlob Frege -
Jean-Christophe Roux -
John Christopher
-
Matias Capeletto -
Yuval Ronen