On Mon, Jan 12, 2015, Borislav Stanimirov
It has been suggested multiple times that perhaps the name "mixin" isn't appropriate, so I was wondering if I can find a better one. [...] My current alternative ideas are:
It would be a mistake to interweave the library description with its title and provide somewhat of an artificial, clumsy name.
* EntityComponent - not great since it doesn't exactly follow the entity-component-system pattern [...]
Close resemblance to ECS does not necessarily force you to select a similar solid name. Quite the contrary, you should pick up a proper name of its own value.
* DynamicMixin - to emphasize that it's not to be confused with the CRTP mixins.
[or, in the same vein, some sort of portmanteau like DynaMix] The very notion of mixin within the OO paradigm implies a combination of behaviour achieved through composition and not by inheritance. As far as CRTP idiom employs inheritance it has nothing to do with the mixin idiom and they are so different in their respective nature one could not reasonably justify an explicit designation of that difference in the name of the library that implements the latter. Detailed coverage of CRTP including a personal account of their initial observation and original implementation here: James Coplien, "Curiously Recurring Template Patterns", C++ Report, February 1995, pp. 24-27.
* Trait - since it resembles the traits in Self, Scala, PHP, etc. However, a trait is more a "compile time" feature
Resemblance to other PLs' features/constructs is of no importance here and may lead to a confusion regarding the usage in C++. The invention of traits and their acceptation in terms of C++ has been given by Nathan Myers 20 years ago ("Traits: a new and useful template technique", C++ Report, June 1995). Stick with the accepted C++ nomenclature.
* TypeComposition or TyCo - a very vague description
Type composition (and subsequent manipulation) is achievable through many different means and mixins are just a particular case of it. Such name would promise everything and provide a fraction of it.
* Polymorph - since it allows the composition of polymorphic types at run time, but that's pobably even more vague
Indeed, that name would cause a great confusion as polymorphism comes in different forms and shapes and your library only provides, as its documentation reads, an alternative [i.e. one more extra] way to accomplish it. * other vague names that you've thought of, like "hameleon" or "zeus" [http://tinyurl.com/hameleon] Hmm, "(C)hameleon", beyond any doubt, is the vaguest of them all... ;)
Other ideas are welcome.
To summarize, the bare fact that the name of the library actually is identical with the programming idiom it implements should, IMHO, be considered a virtue - it's short, self-explanatory and, well, euphonic. Thus, you have all necessary ingredients to firmly bind this unequivocal name with what the library actually sells to the user so that it sticks to his or her mind. And after all, since there isn't a formal library naming convention for Boost collection this isn't much of a problem. In my view, you should leave it the way it is already listed in the Boost review schedule. "Boost.Mixin" is just fine. Get over it! :) Finally, let us hope it will eventually enter, and sooner rather than later, a review process to become part of the Boost Libraries! Best, ~ Yordan ----- ___ A good library is the usable one. -- View this message in context: http://boost.2283326.n4.nabble.com/mixin-Library-name-tp4670940p4672029.html Sent from the Boost - Dev mailing list archive at Nabble.com.