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
