Classes as Sugar is now ready for discussion
Tom Van Cutsem
tomvc.be at gmail.com
Fri Sep 10 00:20:38 PDT 2010
2010/9/10 Tom Van Cutsem <tomvc.be at 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:
> We later switched to a different set of knobs to configure whether the new
> trait instance should be frozen & |this|-bound or not:
> 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'.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss