Abstract functions in child classes
Adam
Adam at anizi.com
Fri Dec 2 11:06:00 PST 2011
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 mean you don't have to type 8 characters?
I've already given you the benefit of requiring it (or in another
argument, but I'm actually assuming you read the rest of this
thread). I shouldn't have to instantiate to test the DEFINITION of
my class. My class is concrete. Or, rather, it WAS concrete. Now
it's not. I have to test this? Unittests making use of an
instantiated case of my class will catch this, but what you're
saying is that, in the absence of a test case instantiating my
class, I have to go ahead and test the definition.
In other words, I've declared this class. At the time of declaring
it, it's concrete. Now I have to add a unittest to *ensure* it's
concrete for an instantiation of this - and all of this ignores my
previous posts and comments about USAGE of my class by others.
The compiler can't get it wrong, of course (and that's a ridiculous
notion, anyway), but it means that something can change implicitly
and transitively.
More information about the Digitalmars-d-learn
mailing list