Mix-ins
Several months ago I promised to write about Eek's mix-in implementation as soon as I have it in the specification. Well, I did finish the specification part, but was never in the right mood to blog about it. The reason for this is that Eek's mixins are actually quite boring. I just renamed interfaces to mixins and gave them the same syntax and capabilities that regular Eek classes have. Like Java interfaces they can still be used as reference types. This, and allowing mix-ins to have non-virtual properties, makes them quite different from many other mix-in (traits etc) implementations, but I think it's the simplest and most powerful way to implement them in a statically typed language. I thought about many other options, like making 'virtual' default for all mixin members (in classes the default is non-virtual) and so on, but eventually I came to the conclusion that consistency is more important than syntactic sugar.

So a Eek mixin could look like this (based on the Cedric Beust example, but with an extra method because Eek does not need accessors):

public mixin Namable
 String shortName
 String longName

 getBothNames(): String
  return "{shortName} ({longName})"
end

To import the mixin, the new "mix" keyword is used instead of "implements":

public class Employee mix Namable
end

And, finally, I did one small but important change to the member modifiers: a member can be "private" and "virtual" at the same time. This has almost same effect as "protected" in C++ and Java, with the difference that only those sub-classes that override the member can access it. I have never liked 'protected' in base classes, but for mixins it actually makes sense.
written at 20:08. (0 Comments, Permalink)