Otaku, Cedric's weblog

"Quantum Software Design" for an idea that's completely unrelated to quantum computing or quantum physics ?

Sorry, I just can't resist a bogus analogy... you make me do it... I claim the idea as MINE!

It's related to quanta... The smallest unit that your code can be broken into.

Maybe we should call then "swanta"... Software Quanta :-)

--
Cedric

Oh, it warms my physicist's heart to see the term Quantum in use here! :) The mix-ins in Java would really help ensuring the Single Responsibility Principle.

Another interesting, albeit slightly different, approach is the "category" concept in Objective-C.
With categories, you don't explicitely import a mixin into a class, but define a category on an existing class, and implement new methods (but no new ivars). Not unlike partial classes in C#, but you can apply that on any class without restriction. Of course, it's quite easy to do in Objective-C as the runtime is very Smalltalkish.

An interesting use is often to add new methods to existing classes from a standard libraries, for adhoc methods adding new behavior to a string class (i.e. 'getMD5Hash') and subclasses. Non-verbose and quite elegant when using it as a regular method. The drawback is of course that the added behavior is not explicit on the extended class.

In actual code, it's more often fine-grain extension than fine-grain decomposition for an new implementation, but it could probably related to the 'quantum software design school of thought' :)

I'm not sure I understand all this, but how is this better then multiple inheritance? Python has multiple inheritance so you can mix via that. Ex.: are there name clashes in mixins?
And I would say this is still is-a so you can't stop someone from using parent class methods not nedded wile with delegation you can.

I like the idea of adding the mixin at the target class instead of in a separate aspect class definition.

I agree, I think this compositional style of OO programming is very powerful and may be a selling point for AOP -- for java at least -- instead of just "cross cutting of concerns" decomposition.

The feature described by Cedric seems to be equivalent to multiple inheritence and quite different to mixins as implemented in Ruby.

I think that language support for delegation in Java might be worth considering.
Something like:

public class Employee {
com.beust.Nameable name;
expose name.setShortname, name.setLongName;
// ...
}

This would be equivalent to defining setShortname and setLongName in Employee to delegate to the name instance variable.

maybe :)
public class Employee imports Nameable, Payable {
}

Smells of multiple inheritence - even if you boil it down to just an under the hood copy/paste.

The 1st & 3rd benefits are available with mulitple inheritence. The 2nd benefit - is that really a benefit ? If you have imported the whole implementation - haven't you got an is-a relationship ?

I miss Multiple Inheritence...as well. Complexity and misuse are no excuse to exclude it.

Peter, I was think it was multiple inheritence as well... but it's not.

Why? Because Employee is _not_ a Nameable.

Inheritence is the inheritance of _type_, with the optional inheritance of _behaviour_. Mixins is the "inheritance" of behaviour, without type. This is the second benefit pointed out by Cedric. Largely because they _don't_ bring in type, mixins avoid a number of problems associated with multiple inheritance. For one thing, mixins have a clear order of import. The "last" method definition always wins (with class-level methods coming "last") in most mixin-based languages.

However, I thought mixins didn't bring in attributes... the m_shortName and m_longName attributes should actually be on the Employee class, I think.

Also, Python already has a well-known mixin technique: http://c2.com/cgi/wiki?MixinsForPython

Mixins would be a good addition to Java. Oh, and mixins are more like the atomic building blocks; the quanta of programming would really be the method. :)

Mixins would be a blessing for any language. I also like how many Rubyians use mixins to organize more complex classes into shorter parts.

I've thought about this before. Basically I want an alternative to cut/paste and inheritance just as you described.

This sounds similar to BUG ID 4191243 on the Java Bug Parade. I think this would be a valuable addition to Java.

Delphi has had this capability for quite a long time now using the 'implements' keyword. This and a few other features like properties and pascal style enumerators are things I really miss from Object Pascal when working in Java.

I don't think it is a good idea. This would pollute Java. Your idea is some sort of MACRO function. The compiler does not enforce the code checks of “imports staffed” class.

The nice thing about "extends" and "implements" is that compiler can check at compile time the contract in the inheritance and implementation.

With "imports staffing" you'd we on your own!

Bad idea indeed.

If you are too retarded to handle multiple-inheritance than you surely won't be able to handle mixins. That is why Java will never include mixins. I mean, duh!

Mixins make me uncomfortable. I think they're a bludgeon to solve for repetitive boilerplate, when a little more analysis of the code duplication and of the reason it exists are in order.

For example, I'd rather solve your problem with a 'has-a'. I think 'Nameable' is confusing the discussion since 'able' screams interface/mix-in.

How about:

public class Name() {
private String shortName;
private String longName;
}

public class Employee {
private Name name;
public Name getName() { return name; }
}

public class Pet {
private Name name;
public Name getName() { return name; }
}

.....

return employee().getName().getLongName();

Yes? No?

Here's where I know my model is weak. Suppose I want to customize the name behavior just for a particular type. Since I've explicitly delegated the name behavior to the Name type in my contract for the Employee class, I've lost some control of it. I have to honor the existence of the Name type and still get my custom functionality in there. For example:

public class Employee {

public Employee(Name name) {
this.name = new EmployeeName(name);
}
...
private boolean isContractor;
...
class EmployeeName extends Name() {
public String getLongName() {
if (isContractor) {
return super.getLongName() + " - CON";
} else {
return super.getLongName();
}
}
}

How would this be accomplished with mixins? Any better?

This approach has a critical weakness in my opinion: Obfuscation.

I much prefer to write employee.getShortName() then employee.getName().getShortName()

Delegation has its uses, but keep in mind what I'm trying to do: reuse an existing implementation made of a few classes so I can expose it *directly* on my class and which I won't have to maintain (if new methods are added, my class will automatically expose these methods as well).

--
Cedric

You're right. The more I thought about it after commenting the more glaring the problem became. And in fact got me started on a whole chain of thinking about the weakness of types that delegate portions of their contracts to code outside of their control. Of course, the quick solution is just to wrap the calls to Name, which is back to your 3rd existing Java solution.

I think mixins are a heavy solution for that particular problem, since they cut through so many aspects of Java type interaction. For example, what if the mixin and the importing class have member variables of the same name? What if one is static and one not? One final and one not? Etc.

As long as you're changing the language, how about a system to essentially promote the methods of member variables? Something like this:

private Name name;

promote Name.setLongName();
promote Name.getLongName();
promote Name.setShortName();
promote Name.getShortName();

Obviously a compile-time rather than run-time directive. It would push those methods up to be available from the promoting type, though the internal Name would be the object the method is actually called on.

Dude, that is exacty what I suggested with my 'export' keyword in an earlier comment. Btw, I think you actually want to say:

promote name.setLongName()

because you might have more than one instance variable of type Name. As long as we're off in language feature creation land, maybe the feature could be extended to handle multiple instance variables of the same type? I.e.

private Person mother;
private Person father;

promote mother.getName() as getMothersName;
promote father.getName() as getFathersName;

Its all just syntactic sugar of course. But then so is ++ and who'd be without that?

Then it is not Java anymore...

Why not to build a new language and fight the world with its adoption!

You could go off and invent cool new ways to hack mix-ins into a language with single inheritance. Or you could go and read about traits: http://www.iam.unibe.ch/~scg/Research/Traits/

If you examine the paper where they refactor the smalltalk collections API: http://www.iam.unibe.ch/~scg/cgi-bin/oobib.cgi?query=nathanael+applying+traits+to+the+collection+hierarchy+oopsla you'll see that they've given this idea rather a lot of thought.

for Mixins in Java using Annotations

See https://rapt.dev.java.net/nonav/docs/api/index.html?net/java/dev/rapt/exploratory/mixin/package-summary.html