On Mon, Oct 10, 2011 at 11:59 AM, Tom Van Cutsem <[email protected]> wrote:
> 2011/10/6 Brendan Eich <[email protected]> > >> 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'? 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. > > 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. jjb
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
