mixin classes vs. abstract classes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

mixin classes vs. abstract classes

Marko van Dooren
Dear all,

I am studying Scala as part of a related work study for a paper on
inheritance. I read the OOPSLA'05 paper "Scalable Component
Abstractions", and was trying to reuse RichIterator under the assumption
that it had been developed as an abstract class instead of a mixin class
(or trait in the paper). I managed to do this, as shown by the code
below, by creating an empty mixin class MixinRichIterator that extends
the now abstract class RichIterator. As far as I see, writing "with
MixinRichIterator" achieves the same as writing "with RichIterator" (if
abstract classes could be used as mixins). So, assuming that the above
is correct, my question is: what is the rationale for not allowing
abstract classes to be used as mixins, but allowing the construction above?

Minor remark on the code in the paper: LoggedIterator and SyncIterator
should be traits (or mixin classes), and not abstract classes. Otherwise
the Iter2 class in the paper does not compile.


mixin class AbsIterator {
   type T;
   def hasNext: boolean;
   def next: T;
}

abstract class RichIterator extends AbsIterator {
   def foreach(f: T=> unit): unit = while (hasNext) f(next);

}

class StringIterator(s: String) extends AbsIterator {
   type T=char;
   private var i=0;
   def hasNext = i<s.length();
   def next = {val x=s.charAt(i);i=i+1;x}
}

mixin class MixinRichIterator extends RichIterator {}

class RichStringIterator(s: String) extends StringIterator(s)
                                     with MixinRichIterator  {
    def m(f:T => unit)  = foreach(f);
}

Regards,

Marko

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm