Re: [boost] [mixin] Library name

Subject: Re: [boost] [mixin] Library name
From: Yordan Naydenov (dax_uktc_at_[hidden])
Date: 2015-02-04 08:45:44

On Mon, Jan 12, 2015, Borislav Stanimirov <b.stanimirov_at_[hidden]> wrote:

> 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.