• Ary Borenszweig <ary esperanto.org.ar> Apr 28 2008
• Christopher Wright <dhasenan gmail.com> Apr 28 2008
• Graham St Jack <Graham.StJack internode.on.net> Apr 28 2008
• Gide Nwawudu <gide btinternet.com> Apr 29 2008
• Bruno Medeiros <brunodomedeiros+spam com.gmail> Apr 29 2008

Ary Borenszweig <ary esperanto.org.ar> writes:

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)

Christopher Wright <dhasenan gmail.com> writes:

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.

Graham St Jack <Graham.StJack internode.on.net> writes:

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)

Gide Nwawudu <gide btinternet.com> writes:

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)

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

vote +1

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