@Malde I think it does. I got in touch with one of the authors of the original traits research paper who said he would take a look at my implementation to make sure it matches their conception of traits, so we should know for sure soon. My implementation does handle the specific case you mentioned correctly (unless one of the conflicting methods is excluded, of course, in which case there is no conflict to resolve).

@Joey Does your library implement correct semantics for Trade composition. For example if one trade composes another and both implement the same method, does this method become a required method of the trait? Joose does not fully hit the required hehavior here. Moose::Role does.

I somewhat agree with your comments re pseudo-classical inheritance in JS. For this reason, JSTraits was designed to be easily plugged into just about any existing inheritance mechanism, including Crockford’s parasitic/beget inheritance to which you allude. As noted in the JSTrait’s documentation, the ‘Class.define’ method is included mostly for testing convenience. The core traits functionality could be (and I hope will be) added to just about any existing JS inheritance mechanism, not just the thin pseudo-classical one I’ve included in JSTraits for examples/testing.

I’d also argue that traits fit very well with prototype based inheritance. Self, the language from which JS pretty much stole its prototype OO model, actually has a feature also known as “traits” that is very similar to what JSTraits provides. The two were a natural fit in Self, and I suspect, just as you do, that the same will be true of JS and JSTraits.

It’s both a blessing and a curse to work in a language that is flexible enough to easily accommodate changes to something as fundamental as the OO system. On the one hand, programmers can easily adapt the language to their own tastes or to better fit the problem at hand. On the flip side, these same customizations can lead to nasty compatibility issues when you try to pull in outside libraries that do not use the same idioms and language extensions of the rest of your code base. I’ve noticed that there is a continuum in this regard with extremely flexible languages like Lisp (defmacro…) populating one end, and more locked down languages like Java populating the other end. JavaScript seems to fall somewhere near the Lisp side.

However, I suspect that this represents some very useful syntax sugar that could easily be adapted to the approaches that Douglas recommends.

A trait is the typed value (e.g. a number, not just a string), associated with an element by an XML attribute or a CSS property. The trait facilities in the SVG uDOM allow for strongly-typed access to certain attribute and property values.