Definition mixins

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Definition mixins

Raul-Sebastian Mihăilă
The first version is based a hundred percent on concepts and mechanisms already used in Ecma262. (Looks like esdiscuss.org has an issue with percentages).

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Definition mixins

T.J. Crowder-2
On Mon, Nov 13, 2017 at 12:25 PM, Raul-Sebastian Mihăilă <[hidden email]> wrote:
>
> The first version is based a hundred percent on concepts and
> mechanisms already used in Ecma262. (Looks like esdiscuss.org
> has an issue with percentages).

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

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Definition mixins

Isiah Meadows-2
In reply to this post by Raul-Sebastian Mihăilă

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.

-----

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.


On Mon, Nov 13, 2017, 07:25 Raul-Sebastian Mihăilă <[hidden email]> wrote:
The first version is based a hundred percent on concepts and mechanisms already used in Ecma262. (Looks like esdiscuss.org has an issue with percentages).
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Definition mixins

Raul-Sebastian Mihăilă
On Mon, Nov 13, 2017 at 4:25 PM, T.J. Crowder <[hidden email]> 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 <[hidden email]> 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.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss