From: "John Maddock" <john@johnmaddock.co.uk>
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.
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
Yeah. 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