As for JavaScript, I strongly believe, Role based composition patterns
like Mixins or Traits should be function based.

Whereas the widely used purely object based approach (together with
some copy mechanics provided by one of the several [extends]
implementations) does still work for Mixins, it is going to fail with Traits.

Traits have to provide/implement functionality for conflict resolution of
methods, for requiring and for excluding them. For JavaScript this can
be achieved easily by just making use of the module pattern and another
function based mixin, that does provide those mentioned composition
methods.

Function based Mixins/Traits have to be applied by [call] or [apply] only.

I always strongly will argue that a function based approach is most
natural for this languages design since it does provide delegation for
free and at the same time also enables injecting of and passing around
additional state for both Mixins and Traits which is another appealing
feature one gets for free too with using [call] or [apply].

And answering the OP's question; Role based composition in JavaScript
should work on both levels instance/object level and class level. For this
reason alone one should not go for using "Classes" as Mixins.

Maybe future language specifications should only describe the syntactic
sugar, that shadows/encapsulates the usage of function based Mixins/
Traits as described e.g. with [1].


[1] The linked article should not be considered spam or selfish - I'm the
author of it. Maybe it helps clarifying my point of view, since it is a brief
deep dive into the matter of Roles, Mixins, Traits, Talents within the context
of JavaScript -
[http://peterseliger.blogspot.de/2014/04/the-many-talents-of-javascript.html#the-many-talents-of-javascript-for-generalizing-role-oriented-programming-approaches-like-traits-and-mixins].


Thanks - Peter



On Thu, Feb 12, 2015 at 5:35 PM, Andrea Giammarchi
<andrea.giammar...@gmail.com> wrote:
> Without going down full specification/implementation details, does anyone
> believe that classes should/could be used, in the future, as traits/mixins
> too?
>
> I find that an anty pattern.
>
> I think traits should be just plain objects with an initializer or some
> special object flagged as trait and I'd rather leave inheritance and classes
> features outside this future feature.
>
> Thoughts? Thanks!
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to