Make 'abstract' mandatory if the class is intended to be abstract, absence of 'abstract' means "not abstract"

[Gide Nwawudu]

vote++

On Mon, 28 Apr 2008 10:11:23 -0300, Ary Borenszweig
<ary at esperanto.org.ar> wrote:

>A class can either be abstract or not abstract. Currently in D, if you 
>don't mark a class as abstract, it can still be it if it contains an 
>abstract method:
>
>class Foo {
>	
>	abstract void someAbstract();
>	
>	void nonAbstract() {
>	}
>	
>}
>
>When designing a class, you have in mind whether the class is going to 
>be abstract or not. If it's not going to be abstract, you want the 
>compiler to help you by telling you "You made a mistake. This class is 
>still abstract because you didn't implement method foo".
>
>So I want to extend Foo with a class Bar, but I want Bar to be not abstract.
>
>class Bar : Foo {
>}
>
>I compile, and it gives no error, of course. But I want there to be an 
>error there. The only way I can get an error is by making a dummy 
>function that instantiates Bar:
>
>void blah() {
>	Bar bar = new Bar();
>}
>
>main.d(14): Error: cannot create instance of abstract class Bar
>main.d(14): Error: function someAbstract is abstract
>
>The problems with this appraoch are two:
>  - You have to make a dummy function to check whether you implemented 
>Bar correctly.
>  - You get two errors for each instantiation of Bar, if it's abstract 
>(ugly).
>
>Why not make "abstract" mandatory for a class if it's intended to be 
>abstract, and the absence of "abstract" to mean "not abstract"? Java 
>works this way, and I think it is for the reasons I mentioned.
>
>Another advantage is that just by seeing the start of class definition 
>you can tell whether a class is abstract or not. You don't have to see 
>if any method is marked as abstract, or go to the superclasses to see if 
>there is a method that is still not implemented.
>
>(also, it would be nice if the compiler could tell you all the methods 
>that still need an implementation, rather than just one)