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)

Ary Borenszweig 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.

You have my support. With the new hiding as an error thing, my faith in Walter thinking of catching stupid errors is shored up, and I have a reasonable hope that this suggestion will succeed.

I agree

On Mon, 28 Apr 2008 10:11:23 -0300, Ary Borenszweig 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)

vote++

On Mon, 28 Apr 2008 10:11:23 -0300, Ary Borenszweig <ary@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)

vote +1

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D