Somewhat hesitantly, I'd like to propose the use of trait rather than mixin. I propose this because mixin emphasizes only the implementation side of thing. (And interface obviously emphasizes only the interface side of things.) I think Scala's trait keyword is nice, short and emphasizes both the interface and implementation aspects.

I understand that Fan emphasizes the concrete, and I agree with that focus (see http://tomobag.blogspot.com/2008/02/scala-more-abstract-and-c-more-concrete.html), but sometimes abstraction is needed, too, and it feels weird to work from the outside of a mixin type.

The reason I am hesitant is that it sounds too much like Scala. Scala folks could look at Fan and say "wannabe", and non-Scala-loving folks could see it and be afraid it looked like Scala. And it might not be a big enough deal to justify the change so late in the game. But I still think it's a better keyword.

Thoughts?

I think you could make a case for either of them - though (at least from my perspective) mixin seems to be the more established term for that concept, so makes for the better term.

To me "trait" has a very specific meaning while "mixin" seems to have a much broader range of meanings. For example in some languages it's just some code template that you can mix into other code parts.

But I'm fine with any name.

I'm not sure there is a good case to switch the mixin keyword - I don't mind making breaking changes, but I want there to be a really compelling reason first. Personally I think mixin describes the concept better - I was a little confused when I first came across the term trait.

OK. Just wanted to throw it out there.

I've no problem with either, mainly because it can be clearly defined, and doesn't have a direct equivalent in Java.

The cases I want to guard against are gratuitously renaming well-known keywords/features from Java.