Abstract functions in child classes

Steven Schveighoffer schveiguy at yahoo.com
Fri Dec 2 07:40:53 PST 2011


On Fri, 02 Dec 2011 09:54:10 -0500, Adam <Adam at anizi.com> 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.

Yes that is the state of affairs.

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

This appears superfluous to me.  A class is abstract either because you  
say it is, or because you haven't fully implemented all methods.

Your same line of thinking is used to promote mandatory overrides, which  
alerts you when something that was an override stops overriding or vice  
versa.  However, we aren't in the same place with abstract, since you  
*can* declare a class abstract even though all its methods are concrete.

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

Exactly.  When you actually try to instantiate Child you find that it's  
abstract.  It's not a silent error (and is caught at compile time).

Now, I can see if you weren't expecting this, and you didn't test it, you  
may end up releasing code that is not what you wanted.  But what are the  
chances someone doesn't test their code before release?

In other words, we only gain from the compiler refusing to compile an  
abstract class not marked as 'abstract' if you don't instantiate it.  How  
often would this happen?

> Overall, the behavior seems "unexpected" (even if it's a personal
> problem).

It's unexpected, but caught at compile-time during development.  The error  
message is clear.  I see no reason to change things.

-Steve


More information about the Digitalmars-d-learn mailing list