[scala] override optional when superclass method is abstract

[Paul Phillips]

abstract class A { def foo:String }
class B extends A { def foo:String = "hi" }
class C extends A { override def foo:String = "bye" }

Scala is cool with it whether or not you specify override in this
(common) situation.  I think it should require one way or the other,
else the inevitably inconsistent subclasses emit needless noise.

--
Paul Phillips      | It's better to have gloved and tossed than never to
Stickler           | have played baseball.
Empiricist         |
pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------

[Jon Pretty]

Hi Paul,

Paul Phillips wrote:
> abstract class A { def foo:String }
> class B extends A { def foo:String = "hi" }
> class C extends A { override def foo:String = "bye" }
>
> Scala is cool with it whether or not you specify override in this
> (common) situation.  I think it should require one way or the other,
> else the inevitably inconsistent subclasses emit needless noise.

No, this does actually serve a purpose, though not one which comes up often.  Consider the
following diamond inheritance:

   trait A { def foo : Int }
   trait B extends A { def foo = 10 }
   trait C extends A { def foo = 20 }
   trait D extends B with C

This - in particular trait D - won't compile.  But if we write

   trait A { def foo : Int }
   trait B extends A { def foo = 10 }
   trait C extends A { override def foo = 20 }
   trait D extends B with C

then it will.

Cheers,
Jon

--
Jon Pretty | Sygneca Ltd

[Jon Pretty]

Hi Paul,

Paul Phillips wrote:
> That is a good point.  I hope this distinction between implementing and
> overriding an abstract method wanders into the documentation around the
> place where they documented the optionality of "override" without
> providing the reasoning.

Maybe.  (And I don't want to start a long discussion on this!)  This is the common
impossibility of choosing the right level of abstraction for a varied audience:  Given the
higher-than-average* number of corner cases afflicting Scala, to present them all to the
user up-front would probably distract from the main theme of any documentation.

Or to put it another way, I can imagine that you could program in Scala all day every day
for a year without finding the optionality of 'override' useful, so why burden the
programmer with that information whilst they're still learning?  Either way, I don't think
there's a right answer, so it's for the judgement of the author...

Cheers,
Jon

* Though rarely without good reason

--
Jon Pretty | Sygneca Ltd