That should do it: http://hg.berniecode.com/java-mixins/changeset/669d0a9f8873

Bernie :o)

still not what I meant but another good point :)
I tried it and it works, @MixinBase can be omitted in extending classes.

What I meant though was I don’t want to repeat “implements Logging” in each derived class. So I tried something else and it works like a charm:

Implemented getInterfaces() in MixinFactory.

	public static List getInterfaces(final Class clazz) {
	    Class c = clazz;
	    List result = new ArrayList(Arrays.asList(c.getInterfaces()));
	    while (true) {
	        c = c.getSuperclass();
	        if (c == null) {
	            break;
	        }
	        result.addAll(Arrays.asList(c.getInterfaces()));
	    }
	    
	    return result;
	}

called it in line 90:

    for (Class mixinType: getInterfaces(mixinBase)) {
        ....
    }

This does the trick, the “Logging” interface need not be declared again in AnotherLoggingClass.

Cheers,
bno

Casting my mind back to the implementation, I see no reason why this issue couldn’t be solved by putting an @Inherited annotation in MixinBase.java. It’s just that annotations aren’t inherited by default, and I never thought about this use case.

That said, since I never tested with inheritance, I can’t guarantee that there’s no part of the system that would break if you just added the @Inherited annotation.

If you try it, let me know!

Bernie :o)

I was talking about a class extending a class implementing a mixin.

Like so:

@MixinType(implementation=LoggerMixIn.class)
public interface Logging {
    Logger getLogger();
}

@MixinBase
public abstract class LoggingClass implements Logging {
    public void doSomething() {
        getLogger().debug("Hello World!");
    }
}

@MixinBase
public abstract class AnotherLoggingClass extends LoggingClass {

    @Override
    public void doSomething() {
        getLogger().debug("Hello World from another one!");
    } 
}

Code generation will fail unless AnotherLoggingClass also implements the Logging interface.

Is there another way to solve this?

Chers,
Bno

Not true – I think you’re confusing annotations and interfaces. In any case, the two classes don’t extend each other, they are composed together.

> And why is MixinSupport a singleton vs. utility class with static methods?

Good question. The reason was that MixinSupport declares an interface (MixinEngine if I recall correctly), so by making it an object, client code can accept any object of type MixinEngine and avoid tying themselves to a specific implementation of the mixin concept. That’s a pretty unlikely use case, but it seemed like a good idea at the time :o)

I like. :)
Very easy to use, no config hassle, nicely done.

One thing though: Inheritance only works when the class derived from a MixinBase again declares the MixinType interface. Which is commonly accepted as bad practice.
It should be possible to detect MixinType interfaces in the type hierarchy… ?

And why is MixinSupport a singleton vs. utility class with static methods?

cheers,
Bno.

I was able to step into the generated code in eclipse because I had set mixins4j to output code to a local folder, then set that folder as a source attachment when eclipse couldn’t find the code the firs time I tried to step in. By default, all code is generated in memory, If I recall correctly there’s a system property that sets a local folder to write files to. Search the source for uses of System.getProperty and you should find the property I used.

You’re right, the @MixinBase could be optional. I made it required because I thought that if I didn’t have a predictable marker on mixin base classes, then the only way of finding the mixins in your project would be to search for uses of MixinSupport (doesn’t work if you instantiate the mixins through reflection, or if you haven’t used a mixin class yet) or searching for classes that implement at least one interface that is annotated @MixinType (doesn’t work if you use a different ImplementationSource that gets implementations from somewhere other than Java interfaces). It’s a matter of taste really, rather than anything scientific.

Bernie :o)

I’ve been looking at all the alternatives for mixins, and I like yours the best. It’s friggin’ awesome!

A question and a suggestion follow.

Question: How did were you able to step into the generated code? I wasn’t able to in eclipse.

Suggestion: I don’t think you really need to have the MixinBase annotation _required_. You use it to get the mixer, but you can use a default for that.

Thanks for the awesome library,

Michael