Traits library

[P T Withington]

On 2010-02-16, at 17:55, Tom Van Cutsem wrote:

> Hi,
> 
> Mark Miller and I have been working on a small traits library for
> Javascript. It is documented here: <
> http://code.google.com/p/es-lab/wiki/Traits>

Nicely done.  A couple of high-level questions.  [Full disclosure:  I'm with OpenLaszlo, and we have our own class/mixin implementation based on prototypical inheritance, built around some extra syntax, transformed by our compiler, and a runtime library; all running in es3 (and as2 and as3).  We haven't yet thought about how we might take advantage of es5.]

1) I understand the motivation for traits (removing some of the magic of mixins), but I don't understand why that needs to be anything more than a lint-like tool, rather than insinuating itself into the implementation.  The fact that you provide the order-sensitive `override` compositor weakens the case for strict traits.  If override combination somehow made the overridden property accessible with a standard name (`super`), it seems to me you would have mixins.  What am I missing?

2) Could you elaborate on this:

> The renaming performed by resolve is shallow: it only changes the binding of the property. If the property is a method, it will not change references to the renamed identifier within the method body.

It seems to me that this 'feature' could lead to more magic than mixins.  If I read this correctly, overriding a method in a trait will be visible to methods outside the trait, but not to methods inside the trait.  That doesn't seem to follow the original traits composition principles.

3) In our usage, being able to test that an object "is" an instance of a mixin is quite important.  In your description, you imply that type testing is an exercise left to the future.  Has this not been an issue in applying your traits library?

4) Your 'stateful trait' example shows why I would call 'class state' and 'each-subclass state' (with the latter recommended, but the former could have applications).  Because your implementation allows any type of property (not just methods), you also have 'instance state' in your traits.  I think this is a good thing.  Perhaps you should make that more explicit, since it diverges from the traits references.

5) I've lost track of where Harmony is heading with classes, but do you have any thoughts on that?  Do you see you traits as an alternative to any other class proposal, or would it be intended as an extension of classes (as the original traits proposal was), should they ever arrive?

P T Withington
OpenLaszlo.ORG/Laszlo Systems