Abstract functions in child classes

[Steven Schveighoffer]

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

> Your presumption is that someone is required to run tests just to
> ensure that their class definition is what they expect. If I define
> a class and it's concrete (because I've defined everything), and
> later someone changes the parent class, my class is no longer
> concrete (it no longer conforms to my intention, despite having no
> way to actually *declare* my intentions in some explicit form). A
> programmer should do testing, but may not (does D require a
> programmer to test? No). You are implicitly testing the *definition*
> of a class, rather than it's *use* (or accuracy, or stability, etc).
>
> Testing or not testing is TANGENTIAL to the issue. Assume that
> someone is not going to do unit test declarations (and do so without
> running off on the wild notion that it's "bad programming," because
> we've already established that). WITHOUT that test, I cannot *know*
> that my class *IS* what I originally defined it to be.

You're being a bit dramatic, no?  The code didn't compile, the compiler  
caught it, and you have invented this theoretical case (which did *not*  
occur) to try and make your point.  I don't deny that requiring 'abstract'  
has some value, but what I question is how much is that value?  Since a  
reasonable developer uses tests (or uses the code in question himself) and  
will end up instantiating any concrete class during testing (or usage),  
I'd say the value is pretty close to zero (not zero, but very close).

But let's assume for a moment that it's standard practice to avoid unit  
testing.  The error that occurs is not a sneaky silent one, it is a loud  
compiler error.  The only risk is that the user of your library finds it  
before you do, because you didn't test, but it still doesn't compile.  Any  
time an error occurs at compile time, it is a win, since the user didn't  
accidentally use something incorrectly.  So here's the solution -- use  
tests.  In my opinion, breaking any existing code to add this requirement  
is unacceptable.

If the base class changes in any way, your derived class may not compile.   
It may break in subtle ways that *do* compile.  If you are going to insist  
on not testing your code after the base class changes, well, then I guess  
you will have to get used to it failing.  Just be thankful if you get a  
compiler error instead of a latent runtime error.

-Steve