Definition mixins

Raul-Sebastian Mihăilă raul.mihaila at
Mon Nov 13 12:18:42 UTC 2017

On Mon, Nov 13, 2017 at 1:54 PM, Bob Myers <rtm at> wrote:

> You should review the TypeScript approach to mixins:

This seems very similar to the naive approach based on Object.assign that I
mention in the first message of this thread. Please see the disadvantages
that I mention there and also note that this approach doesn't provide the
ability to share private state.

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

Could you please provide some more details? The advantages of my approach
to mixins in comparison to other approaches that I mentioned in the first
message also apply in comparison to inheritance.

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

The chess example is just an example. What mixins achieve in general is
sharing a partial definition of a concept in multiple places. Can you
please mention a few of the many, many superior alternatives to achieve
this (please note I'm also interested in using private state)?

> 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.
Did you take a look at the spec I provided? The first version is based 100%
on concepts and mechanisms already used in Ecma262.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list