Classes as Sugar is now ready for discussion

Mark S. Miller erights at
Thu Sep 9 22:12:35 PDT 2010

On Thu, Sep 9, 2010 at 11:31 PM, David Herman <dherman at> wrote:

> > Also, the duality of Object.create vs Traits.create accommodates
> traditional vs high integrity quite well -- without AFAICT compromising
> either.
> It creates a false choice, though (all or nothing).

It does create a choice. What makes a choice false? The traits library is an
open abstraction -- it doesn't encapsulate anything; it only provides some
conveniences for sets of choices that seem to go together. It doesn't
preclude others from making other choices, or from providing further
abstractions for making those choices convenient.

Of course, that doesn't mean we've chosen the right set of knobs. A better
set of knobs would be great. But, IMO, simply having more knobs wouldn't be.

> IIUC, with Object.create, you don't even get the conflict checking. And
> then you've really lost the key benefit of traits.

See <>.
Even with Object.create, you still get conflict detection, but with failure
postponed from creation to usage. This is a more traditionally JavaScripty
way to report failure anyway.

I think there's room for alternatives in the traits space -- for example,
> something similar wrt trait composition, but that didn't bind |this| or
> freeze. That way, you could still integrate traits with the existing
> prototype system. For example, to compose traits to create an object that
> you then use as the prototype for a constructor. This would allow for the
> "vtables" approach and would also give you the ability to specify
> initialization behavior to invoke on instantiation, which you can't do with
> traits.js.

Yes you can:

    function Point(x, y) {
      this.x = x;
      this.y = y;
    Point.prototype = Object.create(

Is that the kind of usage you had in mind?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list