Boost logo

Boost :

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-10-09 06:11:05


>From: "John Maddock" <john_at_[hidden]>

> > I know. :) (They were, however, good examples for the alternative
> > directory
> > structure.) Here are the problematic ones:
> >
> > is_adaptable_binary_function.hpp (32)
> > is_adaptable_binary_predicate.hpp (33)
>
> Do we need the "adaptable" bit?

I found it harder to abbreviate "adaptable" than "function", though.

> If yes, then how about:
>
> is_adaptable_binary_func.hpp
> is_adaptable_binary_pred.hpp

> Maybe not ideal, but as long as you are consistent it should be OK.

Yeah.

> > is_hashed_associative_container.hpp (35) [*]
> > is_multiple_associative_container.hpp (37)
> > is_pair_associative_container.hpp (33)
> > is_simple_associative_container.hpp (35)
> > is_sorted_associative_container.hpp (35)
> > is_unique_associative_container.hpp (35)
> >
> > [*] Ok, not standard yet, but used in the N1443 proposal.
> >
> > As you can see, it's mostly the associative containers that has a
problem.
> > Perhaps shorten the filename (and trait?) "associative" -> "assoc"? That
> > keeps it just under the limit. Then what about the two first?
>
> "assoc" sounds good to me.

Me too.

> BTW, don't get too hung up on names it could be a bicycle shed issue again
> :-)

Don't worry; we have, after all, working code, and the naming issue is not
what is most important.

However, I think you'll agree that names _are_ important, and we're talking
about the public interface, here, not some obscure implementation component.
Recall (or browse) the long discussion to determine the Boost naming
standard, and other requirements, the very same requirements that lead to
the considerations in this thread. I don't think anyone would call the
discussions at the time "bicycle shed"-discussions, either, and for good
reason: they had profound consequences.

I'm not making a big thing out of this - I merely asked, to get some input
from the esteemed members of the Boost community, as it can help to get more
views on an issue, and avoid doing something stupid.

To put this in context: This discussion has spanned a total of 9 messages,
involving postings from 5 people, and responses, over several days. What is
at stake is the names for about 60 type traits - 60 public names, a little
less than the number of traits in the Boost type traits library.

In contrast, the equally recent "Renaming "c++boost.gif"" has spanned _34_
postings, thus far! What is it about? It's about that logo image we have,
its filename and filetype. It might be called "foobar.gif", and hardly
anyone would notice, and it certainly won't break any code. But if you
change the name of 60 traits that are in use, someone _will_ notice, because
their systems no longer work - and neither will any other system using it.

Yet, I don't think the "logo"-discussion is a case of "bicycle shed",
either; just careful attention to detail and portability.

As for the names for the concept traits and "bicycle shed" - I think not!

Anyway, we're keeping the names as they are, for now (except moving to a
single top-level directory "concept_traits"). We didn't really come to an
agreement on whether to shorten the names over directories, or use
abbreviated names for the files.

Regards,

Terje


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk