I wanted to create a class CompileResult, that can be treated like an Either type but has some additional useful methods. It should be a CompileSuccess or a CompileFailure (which, too, has some extended functionality). However I can’t do that because Either is an abstract class and I don’t want to extend it but rather use delegation and have an Either stored internally.
So my question is, why is Either an abstract class now (also why was it a trait before) and why did they not use an interface? Same goes for Option too.
15
The change to Either was made on April 24th, 2008 in commit c0b21797bde81861305dd68853add2d8bd46e484 “Changed isLeft and isRight to use less memory.”:
Changed isLeft and isRight to use less memory.
Changed either from a sealed trait to a sealed abstract class to allow
exhaustiveness checking.All changes per the discussion in #797.
The referenced bug report is SI-797 “lazy vals on Either should probably be defs”:
This comment by David R. MacIver is most illuminating:
While I’m making suggestions, wouldn’t it be better if Either were a sealed abstract class so you could get pattern match warnings?
Note that in the meantime, Scala actually does support exhaustiveness checks for sealed traits as well as sealed abstract classes, so this would no longer be necessary, however, there is also this comment by Geoffrey Alan Washburn:
Given that Left and Right are final, I cannot see any sensible way someone could be using Either as a mixin.
So, it still makes sense for Either not to be a trait.
As for Option, it was sealed in commit 0bef86d8e8b7ea7ebb790ebcec7fedcb9a24f5a8 on March 9th, 2006, however, it was an abstract class even before then.
The change from trait to abstract class was made in commit d7007f7a9607481eb73b8df587e3c52cf4272147 “Use ‘mixin class’ instead of ‘trait'” on March, 3rd, 2006.
As for why they aren’t interfaces, the answer to that is rather simple: Scala doesn’t have interfaces, at least not in the sense of Java or C#.
0