Abstract functions in child classes

[Jonathan M Davis]

On Friday, December 02, 2011 14:54:10 Adam wrote:
> To sort of put my two cents back in, and also to be one of those "D
> should be like Java!" advocates, the problem is largely that a class
> that inherits from an abstract and does *not* override some abstract
> member becomes implicitly (to the user) abstract.
> 
> The way abstracts work in Java is that, in order to maintain that
> "child" is an abstract (so that the actual implementation is
> GrandChild), you must declare that both Child is an abstract class
> and redeclare the function in question.
> 
> Now, perhaps there are good reasons in D for not requiring Child to
> be declared abstract, but I'm not sure what they are. If a class
> having any members that are abstract is implicitly abstract, then
> the programmer should probably have to declare that the class is
> abstract, as well.
> 
> The problem I ran into is that, until instantiation, the only way I
> knew that Child was abstract would have been to go look at Parent
> and see that I had forgotten to override a method.
> 
> Overall, the behavior seems "unexpected" (even if it's a personal
> problem).

The class is abstract whether you mark it that way or not, because it has 
abstract methods. All marking the class as absract is going to do is give the 
programmer a visual clue that it's abstract. So, arguably, it really doesn't 
matter. Now, I personally think that it should be required if the class is 
abstract, since it's more consistent that way, but it's not going to have any 
effect on error messags are anything like that. From the compiler's 
perspective, there just isn't any need.

- Jonathan M Davis