I believe I've done this with Dynamic Proxies in Java. Basically, as long as the Mixin is an interface. Proxy can create a class that implements all of the interfaces you specify, your InvocationHandler just needs to take your Mixin and the object that is mixing with, and dispatch to the correct object based on the method being executed.

> I believe I've done this with Dynamic Proxies in Java.> Basically, as long as the Mixin is an interface. Proxy> y can create a class that implements all of the interfaces> you specify, your InvocationHandler just needs to take> your Mixin and the object that is mixing with, and> dispatch to the correct object based on the method being> executed.> > Let me know if you need some example code...

It would be intesting to see my Mixins.java example expressed this way, since I've also done it using the Decorator. That way it could be compared.

> Hi,> > I have used and found following pattern useful > http://www.cs.luc.edu/users/laufer/teaching/473/handouts/Ab> stractSubclasses.html> It describes how you can simulate mixins in java. I have> used this technique in one of my projects. Major> advantange I think mixins provide is module reusability.> If you want to reuse just using inheritance, you have to> duplicate either base or derived class definitions.

I'm not sure how you could have used this technique. His final section "Implementation in Java?" says that this approach does not work. The code he shows will not compile, and he explains why. That article is an exploration and description of the problems, but not a solution.

Perhaps you have an example that shows how you have applied this technique?

Its not possible to extend existing class as template parameter. But you can simulate inheritance explicitly. Here is the example from the same site.

/** * Application-independent support for base classes and mixin classes. * Conceptually, an instance of this class has a superclass instance * (whose methods are statically bound) and a current receiver * (whose methods are dynamically bound). */

class Composable {

/** * The static superclass instance for this object, that is, the next * object up the conceptual inheritance hierarchy. */

protected Composable zuper;

/** * The dynamic receiver instance for this object, that is, the object * at the bottom of the conceptual inheritance hierarchy (beginning * of the chain of responsibility). */

/** * Application-specific support for base classes. Subclasses should * implement all methods in the application-specific interface, that is, * Collection. For convenience, it provides application-specific * accessor methods for thiz and zuper. */

/** * Application-specific support for mixin classes. Subclasses should only * implement those methods in the application-specific interface that they * want to refine. For convenience, it provides default implementations * of all methods in the application-specific interface; this simulates * method inheritance. */

/** * An example implementation of Collection to be used as an * abstract subclass (mixin) for adding the SizeOf capability * to an arbitrary Collection implementation. Note that methods * from the superclass in the conceptual sense must be invoked * via getSuper. */

/** * An example implementation of Collection to be used as an * abstract subclass (mixin) for adding the Verbose capability * (reporting on every operation) to an arbitrary Collection * implementation. */

Timestamp and Serial numbers are not normally part of the actual "business logic" of the class. They are only necessary to actually implement the business logic.

So, you implement serial numbering and timestamping in an aspect, and then you weave that aspect into the parts that need them in order to behave properly at compile-time or configuration-/load-time.

The same thing goes for other cross-cutting concerns like being transactional, logged, asynchronous etc. In my current project we introduce or wrap such stuff around the implementation classes so that the developers only have to see or care for the business logic.

Mixins are used to separate functional aspects from non-functional aspects. It is not a design flaw but one of the problems that OO cannot solve in a really reusable way. We should consider AspectJ or any such tool instead of tacking on everything to java.

My toying with Ruby has been giving me some lanaguage envy lately, and so has chatting with friends who do serious work in Eiffel. I was glad to see this article, as it clearly discusses one of the precise things I am missing.

I know Java will never be Ruby, but I'd love it if someone more familiar with Sun's internal workings could talk about how much future versions of Java might make bold strides forward like 1.5 did. Will we ever be able to write something as developer-friendly as Rails without going as deep under the hood as, say, Hibernate does?

I'm currently reading Bruce Tate's "Beyond Java" which addresses some of these issues. He's a little fast and loose in places, but it's thought-provoking nonetheless.

On more than one occasion when I've pointed out issues and what I percieve as shortcomings in the language, I've gotten the rather tautological answer "that's not Java." Or sometimes "Java is what it is, and you're asking for something that isn't Java," as if it leaped fully formed from the forehead of Gosling and there's nothing that can be done about it, so love it or leave it. I don't think this attitude has done the language a service for a long time; indeed, it took the fire lit by C# for J2SE5 to come about. Many of these new language features were ones that we were patiently told that we didn't really need -- until they appeared in C#. Now C# 3.0 is departing even further from Java, with things like type inference, and I doubt Java will go there.

There were plenty of papers and studies about Java mixins before J2SE5 came out, and nothing was included. It appears that mixins were something else that we "don't really need." So I wouldn't hold my breath for this one. Tate's attitude seems to be "it ain't gonna happen."

> Those appear to be what are called "Multimethods," which> you can also find in the Nice language. But yes, another> way to paste methods into an existing class. There seem to> be a number of approaches to this, and I've never seen a> comparison -- they tend to be expressed independently,> without a sense of "what would mixins give you that> multimethods wouldn't," etc.

No, multimethods dispatch on all arguments to the method. C# only allows dispatching on the first argument to the method; it's just providing a way to explicitly specify what the first argument is (outside of the defining class).