2011/10/10 Dean Landolt <d...@deanlandolt.com> > > On Mon, Oct 10, 2011 at 4:13 PM, John J Barton < > johnjbar...@johnjbarton.com> wrote: >> >> On Mon, Oct 10, 2011 at 11:59 AM, Tom Van Cutsem <tomvc...@gmail.com>wrote: >> >>> The traits philosophy is that, when merging objects, you want to see name >>> clashes flagged as exceptions (to prevent inadvertent overriding). That's >>> why an additional operation like Trait.resolve() is needed to deliberately >>> avoid those conflicts. I gather than the philosophy of Object.extend is that >>> src always overrides dest properties. That's a different philosophy, but >>> that's fine. >>> >> >> Isn't this a case of 'up front pain' vs 'bites me later pain'? >> > > > Yes, compile-time errors (rather than run-time) are a fundamental feature > of traits. >
Indeed. Or, if compile-time is unattainable, at least a "composition-time" error (i.e. when Trait.compose is called). > src overriding dest is clearly less up front pain since collisions are >> resolved by rule, but it makes the composition non-commutative, meaning that >> if you later reverse the order of the composition code can break, esp. >> dependent objects. >> > > > Precisely. Traits allow composition without an MRO algorithm. Further, they > allow remapping fields or methods, allowing strictly more power to composers > than an MRO can promise. > > > An orthogonal issue is whether Object.extend / Trait.override should be >>> functional or imperative. For traits.js I deliberately chose a functional >>> API. Traits can be used in several different compositions, and you don't >>> want any of those compositions to side-effect your traits. For >>> Object.extend, the common use case may be different. >>> >> >> Sorry to be dense, but can you say a bit more about what you mean here. >> > > > I *believe* what Tom is suggesting is that Trait.override returns newly > minted traits rather than mutating, and depending on the usecase, this could > be unnecessary and/or too costly. > That is what I meant, thanks for clarifying. Cheers, Tom
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
