Classes as Sugar is now ready for discussion

Tom Van Cutsem at
Fri Sep 10 00:04:03 PDT 2010

> 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...
URL: <>

More information about the es-discuss mailing list