If you are using mulitple inheritance to reuse code, you should think twice (even with regular inheritance). Unless there is a meaningful is-a relationship, this is best accomplished via composition.
If you are in the Java world, this is where it pays to switch some classes to Groovy and use its @Delegate annotation. It's a compile-time AST transformation, such that straight-up Java code can take advantage, and it can inject the delegated interfaces into its parent class (so now the class can show up as implementing an interface for the dependency injection framework).
This can be introduced on an as-needed basis (make some files Groovy and the Java code can call them) and Groovy is essentially 95% compatible with identical Java code, so you can usually rename .java to .groovy and be good to go.
> If you are in the Java world, this is where it pays to switch some classes to Groovy and use its @Delegate annotation. It's a compile-time AST transformation
"If you are using mulitple inheritance to reuse code, you should think twice (even with regular inheritance). Unless there is a meaningful is-a relationship, this is best accomplished via composition."
I wish Java had no inheritance at all. So many painful moments of misuse, overuse and high coupling and a deep maintenance hell. worst:people think they rock...
More evidence that if a language lacks macros, people will find an alternate mechanism for language extension (bytecode generation) which is usually much more complex than macros would have been.
On the other hand, reflection in the hands of over-eager users is already a nightmare... perhaps a huge speed bump in the way of full metaprogramming is a good thing for most projects.
As far as the actual application presented here.. it doesn't quite get you Scala's traits (no self-types) but it seems pretty close. Nice hack.
Experimenting is a great idea, that's how we learn, but using your experiments in a production environment is a completely different matter, and usually a bad idea.
If you are in the Java world, this is where it pays to switch some classes to Groovy and use its @Delegate annotation. It's a compile-time AST transformation, such that straight-up Java code can take advantage, and it can inject the delegated interfaces into its parent class (so now the class can show up as implementing an interface for the dependency injection framework).
This can be introduced on an as-needed basis (make some files Groovy and the Java code can call them) and Groovy is essentially 95% compatible with identical Java code, so you can usually rename .java to .groovy and be good to go.