So we agree traits are not classes and notions, as well as functionality,
is different. Then why would you us `class` to define a trait?

How are you going to recognize them?

I have a library that works already out of the box with traits but these
are not classes, just objects that will enrich classes.

Overriding methods means having a warning in console, instead of throwing,
and nothing else.
You compose whatever you want, order of defined mixins/traits matters, as
well as eventual initialization of each trait.

The latter one, is available already once each instance is defined, inside
the constructor.
This works to me, and I'd rather avoid the burden to walk all inheritance
chain if I have to accept classes too instead of objects, but I wouldn't
mind implementing it as long as I understand why that's a good thing to
have in JS.

Best Regards


On Thu, Feb 12, 2015 at 9:28 PM, Luke Scott <luke at cywh.com> wrote:

> Traits are different than classical inheritance. They simply copy
> functionality into a class as if the method was actually defined in the
> class. It isn’t inheritance. It allows you to DRY.
>
> A real world example in my ES6 project:
>
> - Node
> - Element extends Node
> - Field extends Element
> - TextField extends Element
> - Select extends Element, mixin Parent
> - Option extends Element
> - Fieldset extends Element, mixin Parent
>
> In this case (subset of my class structure) a Fieldset has child
> Nodes/Elements/Fields. A Field and TextField does not have children. Yet,
> Select has specific child nodes. I use a trait to mixin the Parent trait to
> reuse functionality. Select is a parent because it has the trait, but the
> parent class Field is not a parent. In my case it makes no sense to
> re-implement that in Select, especially when having the Parent trait means
> something when building something like a lookup table.
>
> I think it’s important to note that a trait knows very little of the class
> that implements it. For example I may mixin Parent into Select or Fieldset,
> but I restrict myself to methods found in Node (my base class) to be able
> to use the trait in any situation. If I need functionality from another
> trait, I mixin the other trait to make one trait.
>
> On Feb 12, 2015, at 12:07 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
> So you are saying we can just forget about extends keyword and use mixin
> instead for everything, right?
> ------------------------------
> From: Alex Russell <slightlyoff at google.com>
> Sent: ‎12/‎02/‎2015 20:05
> To: Andrea Giammarchi <andrea.giammarchi at gmail.com>
> Cc: Luke Scott <luke at cywh.com>; es-discuss at mozilla.org
> Subject: Re: about lightweight traits
>
> Traits as class make perfect sense when you consider that classes are
> functions and so are traits.
>
> On Thu, Feb 12, 2015 at 10:27 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> this thousand times ... Traits as class makes no sense to me indeed and
>> Mark example shows plain objects passed as Trait.create ... that works just
>> fine, except some trait initialization, which should not be a constructor,
>> could be used too.
>>
>> Is there any other language that uses same classical OOP classes as
>> traits too? It really does not feel right to me.
>>
>> Btw, reason I'm asking is because somebody else asked, I'm really OK to
>> not rush and wait to see how it goes when it's the right time.
>>
>> Best Regards
>>
>> On Thu, Feb 12, 2015 at 6:32 PM, Luke Scott <luke at cywh.com> wrote:
>>
>>>
>>> On Feb 12, 2015, at 8:35 AM, Andrea Giammarchi <
>>> andrea.giammarchi at 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!
>>>
>>>
>>> I would agree with that. I had a trait implementation that used classes
>>> as traits, and it caused a lot of problems, especially since classes have
>>> constructors. Traits should not have constructors. I have since updated my
>>> implementation to use plain objects.
>>>
>>> This is what I am using now:
>>> https://gist.github.com/lukescott/36453a75c39c539f5c7d
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150212/a120a396/attachment.html>

So we agree traits are not classes and notions, as well as functionality,
is different. Then why would you us `class` to define a trait?

How are you going to recognize them?

I have a library that works already out of the box with traits but these
are not classes, just objects that will enrich classes.

Overriding methods means having a warning in console, instead of throwing,
and nothing else.
You compose whatever you want, order of defined mixins/traits matters, as
well as eventual initialization of each trait.

The latter one, is available already once each instance is defined, inside
the constructor.
This works to me, and I'd rather avoid the burden to walk all inheritance
chain if I have to accept classes too instead of objects, but I wouldn't
mind implementing it as long as I understand why that's a good thing to
have in JS.