Luke, forgot one detail: you do not explicitly initialize traits, these are
initialized if these have an `init` or `initialize` method defined, and
before the constructor is executed. So, using you example code:
```js
trait Trait1 {
initt() {
this.trait1Data = {what:'ever'};
}
}
class Trait1 {
mixin Trait1;
constructor() {
console.log(this.trait1Data);
// {what:'ever'}
}
}
```
That makes them really portable, the class is instantly aware of them since
it used them as mixin, but traits are fully independent.
Do you need a lazy trait? Then you can expose an explicit method to
set-it-up and invoke it whenever you want in your constructor.
Does any of this make sense? It works already in some case of mine :-)
On Thu, Feb 12, 2015 at 9:42 PM, Andrea Giammarchi <
[email protected]> wrote:
> Luke, answering in order:
>
> 1. defining order, first come, first serve ... same as everything else on
> daily usage (events, Array of callbacks, etc)
>
> 2. You do not ever pass parameter to them, parameters are constructors
> matters, traits should be independent and unaware of constructors arguments
> otherwise you loose portability.
> A trait should be able to work and enrich any sort of class, not just some
> specific one it has no notion about.
>
> 3. before everything else, since these should be stand-alone behaviors
> unrelated with constructors
>
> All marked as IMO, of course :-)
>
>
> On Thu, Feb 12, 2015 at 9:33 PM, Luke Scott <[email protected]> wrote:
>
>>
>> > On Feb 12, 2015, at 12:11 PM, Domenic Denicola <[email protected]> wrote:
>> >
>> > From: es-discuss [mailto:[email protected]] On Behalf Of
>> Benjamin Gruenbaum
>> >
>> >> We have `Object.assign` that works fantastically for most classic
>> trait use cases.
>> >
>> > Well, actually, it works extremely poorly. The old (now dead or
>> deferred) `Object.mixin`, once called `Object.define`, is a better fit. But
>> it still fails to account for a couple things, off the top of my head:
>> >
>> > - Being able to add custom initialization logic to the class
>> constructor when "mixing in" a trait. You can construct a custom protocol
>> around this, but (a) that means the class you're mixing in to needs to be
>> aware of the protocol; (b) everyone needs to agree on a protocol across the
>> ecosystem.
>> > - Pretty much anything to do with private state doesn't work anymore.
>>
>> The biggest issues of trait initializers are (constructors) are:
>>
>> - What order do you call them in.
>> - How do you pass in parameters into them.
>> - They would need to be called by the class constructor. Does this happen
>> at the beginning or end?
>>
>> I would argue that traits should not have initializers. It’s much easier
>> to do something like this:
>>
>> trait Trait1 {
>> initTrait1() {
>> // this is a regular method
>> // init trait here
>> }
>> }
>>
>> class Trait1 {
>> mixin Trait1;
>>
>> constructor() {
>> // do work here…
>> this.initTrait1()
>> // do more work here...
>> }
>> }
>>
>> This kind of pattern makes initializing traits more intentional and
>> leaves out any assumptions of what the correct order would be. And not all
>> traits need initializers, so it leaves out a lot of complexity.
>>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
