I.e. Different implementations to produce the similar output. Using an Interface just says that it needs to be capable of singing, but doesn’t assume it knows how the thing sings.

Honestly if they really function that much alike in how they sing, you can probably add a “Singer” class and just use composition (interface Singable {Singer getSinger();}. Then implement the “default” singer and extend it as needed. So you’re really only saving the difference in keystrokes between “with MixinName” and “return this.singer;”

The only real utility of mixins that i’ve seen is meta computing. Things like equality checking, comparison, reflective data conversion (object to json/xml) etc. Where the “type” you’d pass to the mixin function would be Object and comparing any object to any other. Like if something should be sorted by it’s numeric field, numeric sorting always works the same way so the method you’d write implementing the “comparable” interface would be the same from class to class. The mixin/trait there would save you the time, because the “default” implementation is likely to always be the same, regardless of the class. Exceptions can then be overriden.

In your example, i can totally see mixing in Singer but then needing to actually override sing() in every class that uses it because if they probably have different internals for HOW they sing.

Cheers

Thanks,
Santhosh

many thanks for your nice feedback!

In fact i also had to think about Qi4Js mantra of ‘Composite Oriented Programming’ when hearing the first time of Scala’s possibilities to use traits as mixins.

Greetings

Mario