From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-08-24 16:13:42
> > > The alternative should be, IMO, a shorter name, not an acronym. If
> > > full word names can't be found, then abbreviations.
> > >
> > I agree in prinicple that acronyms are bad. However, I can't think of
> > anything better for this particular name. I also want to keep the
> > aural analogy to the well-known acronym "STL".
> I tend to agree that the MPL name works well for me, but I do agree that
> it may be obscure for new Boosters (though, as Peter noted, I'm not sure
> that a new name will make MPL particularly easier to understand for new
> So one thought is to rid of the mpl namespace (!) and prefix every MPL
> class with meta_ (e.g., boost::meta_if, boost::meta_max_element, etc.).
> Then the library and its corresponding libs/path could be as verbose as
> desired (e.g., libs/template_metaprogramming), as components would be
> #included via "boost/meta_XXX.hpp" (and perhaps a mass-#include via a
> "boost/template_metaprogramming.hpp" header).
> To tell the truth, I don't even like my own proposal, but it might be
> helpful to move the discussion along (even if to just say no) :-P
I am in agreement with your not liking your own proposal ;-)
My proposal would be that, in cases where a short, concise, yet descriptive
name cannot be (easily) found - as seems to be the case with MPL, maybe the
solution is very simple: when we refer to the library anywhere in
documentation, in the list of libraries - folder names etc... we use the
full name. Within the code, however, we make the concesion to use the
abbreviated form for the namespace.
Of course, in general we should still strive to avoid this - and it seems to
have been much easier for, for example, boost.graphs and boost.datetime (or
whatever it ended up being called).
Just my 2 <insert local currency>'s worth,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk