:s/niche/demand 2010/9/10 Tom Van Cutsem <tomvc...@gmail.com>
> Is the on-demand nature of conflict detection (for traits built with >>> Object.create) somehow unavoidable, or was that simply a design choice? >>> >> >> It actually was a design choice dating from before we switched to >> Object.create. Originally, we had a high-vs-low integrity switch in >> Traits.create. As Tom was implementing our design, he noticed that the low >> integrity case simplified down to being identical to Object.create. Seeing >> that, Tom realized that we didn't actually need a switch as people could >> just use Object.create directly. >> >> Tom, do I have the history of that right? >> > > Yes, that's an accurate summary. It also brings me back to Dave's earlier > question about the limited choices provided by the Traits > library. Initially, our Traits provided more fine-grained control over > freezing, |this|-binding, etc. Performing some code archaeology on the > traits.js source code reveals these options: > > We started out with a set of knobs to configure whether trait composition > errors would be flagged early or not: > > http://code.google.com/p/es-lab/source/browse/trunk/src/traits/traits.js?spec=svn177&r=177#211 > > We later switched to a different set of knobs to configure whether the new > trait instance should be frozen & |this|-bound or not: > > http://code.google.com/p/es-lab/source/browse/trunk/src/traits/traits.js?spec=svn232&r=232#418 > > As you can see from the code comments, we lumped together various options > into a single switch, based on what we thought were the common use cases. > Eventually, we realized that instead of such a switch, we could use > Object.create vs Trait.create for similar effect. > > Long story short: it's definitely possible for a Traits library to offer > more knobs, although I'm not sure whether the increased complexity is worth > it. Judging from earlier comments, it seems there is at least a niche for > the combination of 'early conflict detection' + 'non-frozen, > non-|this|-bound objects'. >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
