Definition mixins

Raul-Sebastian Mihăilă raul.mihaila at gmail.com
Mon Nov 13 15:49:01 UTC 2017


On Mon, Nov 13, 2017 at 4:25 PM, T.J. Crowder <tj.crowder@
farsightsoftware.com> wrote:

>
> There's an Edit link on messages on esdiscuss.org to let you fix issues
> like that (e.g., when there's some esdiscuss.org-specific issue).
>
Cool, thanks!

On Mon, Nov 13, 2017 at 4:48 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> May I point out a few things:
>
> 1. The React community, who has for most of its existence used mixins and
> pseudo-proxies (they call them 'higher order components", but they're
> basically component proxies) is now moving to this thing called a "render
> prop", which is basically a function argument returning children. This is
> because mixins don't compose nor scale.
>
> 2. Elm, a compile-to-JS language/front-end framework (it's both),
> separates the model from the view, and the view is a function from model to
> vnode tree. When you use a child component, you store the child's model in
> the parent model, and you pass that state to the child's view when
> rendering the parent's view. There exist JS microframeworks that implement
> this flow for JS as well.
>
> 3. It's common practice in Angular to use dependency injection and
> directives where most others would use mixins. Angular dropped mixin
> support because of similar scalability issues.
>
> The whole point of these examples is to state that mixins aren't critical
> enough to be added to the language. It's perfectly fine as a library, but
> it's not something we should include in the language.
>
It's good that you're bringing these up. First, I think communities aren't
(and probably shouldn't always be) so cohesive. It would be interesting to
see what percentage of React users use the render prop thing. Assuming that
there is such a movement, this shows an evolution and I don't see any
reason to believe that the render prop is the end of it. Therefore, I don't
think it's safe to conclude that what we have now is good enough and that
because it's good enough we don't need anything else. It's important to
note that the React mixins are quite different from what I propose. They
have all the issues that I mention in the first message. If they didn't
have those issues, they would have probably had a different life.

What you say about Elm sounds good. I don't see how it's related to this
topic. I'm not saying use mixins for everything. However, you might want to
(not necessarily in Elm) use mixins to partially define some of your
models, in order to reuse code, without running into issues that you could
get with inheritance. I'm definitely not using mixins for views, and if I
think about it not even for controllers, but I do find them very useful for
models.

If some sort of mixins proved to not be useful for certain things, it
doesn't mean that they aren't useful for anything. I don't know how Angular
used mixins (I'm not experienced with Angular2). Are those Typescript
mixins? Then they share some of the issues with the React mixins. It's
difficult to say how much of this bad experience people have had with
mixins is due to the concept itself, to the particularities of the mixin
approaches or to the fact that some people prefer a more functional
approach and run away from everything that looks object oriented. I haven't
seen a mixin approach in Javascript similar to this approach and that
doesn't have at least some of the issues I listed in the beginning of this
thread and I think it's important to be aware of this when balancing out
mixins.

> Oh, and fun fact, some languages, like Elm and Haskell, don't even provide
> means for creating mixins, even through interfaces. Instead, they use
> functions exclusively to define extended functionality.
>
That's good, not all languages are the same. Yet, Javascript is an object
oriented general purpose programming language. Not only for UIs. Perhaps a
separate topic regarding the direction TC39 wants to take WRT to OOP vs
functional programming would be interesting. I personally think Javascript
should continue to support both. Reusing code is essential and the basic
ways of doing this in an OO style are composition and inheritance. Mixins,
in this approach, are another kind of composition.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171113/d8081117/attachment-0001.html>


More information about the es-discuss mailing list