> On Feb 12, 2015, at 12:11 PM, Domenic Denicola <d at domenic.me> wrote:
> 
> From: es-discuss [mailto:es-discuss-bounces at mozilla.org] 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.

On Feb 12, 2015, at 12:11 PM, Domenic Denicola <d at domenic.me> wrote:

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

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:

```js
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.