Boost logo

Boost Users :

From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2007-02-18 22:22:09


On 2/18/07, Matias Capeletto <matias.capeletto_at_[hidden]> 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_tutorial/discovering_the_new_framework.html
>

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net