Definition mixins

Bob Myers rtm at
Mon Nov 13 11:54:38 UTC 2017

You should review the TypeScript approach to mixins: https://www.

But more generally, mixins are a very specific, opinionated OO design
pattern. They are probably misused more often than not. If you think that
big class hierarchies were brittle and hard to maintain, just wait until
you include mixins. There are many, many alternatives to modeling things
like "can move more than one square at a time in some direction", and most
of them are, at least in my opinion, superior to mixins. It is also not too
hard to make the case that mixins are somewhere between difficult and
impossible to implement properly in a language which doesn't have proper
built-in support--the fundamental notion of prototypes in JS, which
underlies its classes, can be considered mixin-hostile.


On Mon, Nov 13, 2017 at 3:09 PM, Raul-Sebastian Mihăilă <
raul.mihaila at> wrote:

> On Mon, Nov 13, 2017 at 10:54 AM, T.J. Crowder <
> tj.crowder at> wrote:
>> Could you add a "Motivations" section outlining why this is needed and
>> what alternatives currently exist without new syntax?
> It would be indeed worth adding such a section in the proposal, but for
> now please take a look at the first message in this thread in which I do
> mention why this syntax is useful and current alternatives.
>> Separately, without yet having delved into the details, various parts of
>> the "without mixins" code look suspect, for example:
>> ```js
>> const isSafeMove = mix.isSafeMove = boardMixin.isSafeMove(mix);
>> ```
>> That *calls* the `boardMixin.isSafeMove` function, passing it the `mix`
>> constant, and assigns its return value to `mix.isSafeMove` and a new
>> constant `isSafeMove` (which confusingly doesn't seem to be used anywhere).
>> Should it really be *calling* the function? Not binding or something?
>> -- T.J. Crowder
> Please do delve into the details (especially the first message in this
> thread). The first message shows how the mix object is used. Without mixins
> syntax, the mix object has two purposes, it holds the mixin functions that
> are provided by mixin function providers so that you can call a mixin
> function in another mixin function. This mix object is passed to the mixin
> function providers, so that the mixin functions that they create can use
> the object. However, since an essential part of this proposal is the
> ability to share private state with the mixin functions, the mix object
> also contains the private state to be shared.
> The reason the `isSafeMove` constant is created is to be able to easily
> call the function in the current context, without having to use the mix
> object. It's a nice to have. The mixin syntax not only makes this possible,
> but it also provides the separation between holding the mixin functions in
> an object so that they are accessible in the mixin functions themselves and
> sharing whatever private data needs to be shared with the mixin functions.
> This separation would have also been possible without the mixin syntax.
> However, the syntax is much simpler with this proposal: the constant
> binding is created, or the function can become a public method of the
> object, you don't need to create and handle the mix object and this also
> works with private fields in a class context. Also, the second version of
> the proposal is based on the possibly controversial idea of indirect
> bindings in a function context.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list