Abstract functions in child classes

[Steven Schveighoffer]

On Fri, 02 Dec 2011 11:05:00 -0500, Adam <Adam at anizi.com> wrote:

> I'm not sure how the fact that a class can be abstract with defined
> functions impacts the case either way.
>
> It's caught at compile time, but it requires explicitly testing that
> any given time is or is not instantiable - how else would you test
> for this particular case? It seems to be adding an additional test
> case wherein for every abstract or implementation of abstract (or
> supposed implementation of abstract, as is my case), you must test
> for instantiability.

How do you run your normal tests without instantiating?  There is no need  
to test instantiability, since it's implicitly tested in your unit tests.

> If you admit that the error is unexpected, but caught at compile-
> time and only if you actually test for the specific case of if a
> given implementation *is* instantiable, then you've clearly
> demonstrated that the lack of a mandatory re-declaration of an
> abstract results in an additional test case.

No.  It's covered by testing the functionality of the class.  You must  
instantiate to test anything related to the class.

> To step back a bit, what is the *benefit* of not requiring a class
> to be declared abstract if it does not override an abstract member?
> It introduces implicit behavior and the potential for an additional
> test case (in *what* sane world should I even HAVE to test that
> something is instantiable?) for the sake of not typing 8 characters
> in a Class definition

The benefit is, I don't have to declare something is abstract *twice*, I  
only have to do it by leaving the function unimplemented.  This does not  
stop you from putting abstract on the class if you want to add that extra  
documentation.  The doc generator probably can put whether the class is  
abstract directly in the docs anyway.

The burden of proving benefit is on *changing* the language, not leaving  
it the same.  What benefit is there to requiring it?  You already have to  
instantiate to test the class, or use it, so what is the risk of not  
letting the compiler imply it?

Contrary to something like function purity, which must be declared on the  
function signature for prototypes, you always know all the members of a  
class and its base classes.  There is no hidden information, and no chance  
the compiler could get it wrong.

-Steve