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: > >> 2011/10/6 Brendan Eich <bren...@mozilla.com> >> >>> On Oct 5, 2011, at 9:02 PM, John J Barton 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. > 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.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
