Classes as Sugar is now ready for discussion

Tom Van Cutsem tomvc.be at gmail.com
Fri Sep 10 00:20:38 PDT 2010


:s/niche/demand

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:
>
> 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'.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100910/b3c4b720/attachment-0001.html>


More information about the es-discuss mailing list