On Mon, Oct 10, 2011 at 5:06 PM, John J Barton <johnjbar...@johnjbarton.com>wrote:
> > > 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. > I suspect we have different definitions of tedious. Having my program immediately inform me of a potential conflict, tell me precisely where it is, and give me the tools to easily resolve it strikes me as a lot less tedious than learning of some odd behavior after the fact and rooting through the details of some MRO algorithm to try and tease out what it could be. > 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. > I'd argue it always matters. If there's no conflict, there's no work. If there *is* a conflict, you'll almost certainly want to know about it. You obviously believe differently, but I suspect you may not be aware of just how little work we're talking about here. > 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. > If you accept the premise that all method name conflicts are at least problem enough to warrant a second look then I believe traits are clearly superior.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
