On Mon, Oct 10, 2011 at 1:45 PM, Dean Landolt <d...@deanlandolt.com> wrote:
> > > 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. > Or: create tedious work all of them time rather than doing what you want 99% of the time. > > > >> 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. > Or: require composers to explicitly specify extra details whether it matters or not. Personally I don't think either approach is intrinsically superior. I don't think any of the library implementations choice to make extend() throw errors on collisions. jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
