Abstract functions in child classes
Adam
Adam at Anizi.com
Fri Dec 2 08:05:00 PST 2011
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.
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.
This *appears* to be at odds with a few of the other things I've
seen in D, which goes out of its way to ensure you do *not*
accidentally do things. In particular, I'm thinking of concurrency,
which does not even *allow* function-level synchronized declaration
(though it does allow synchronized blocks within functions) - it's
either at the class, or not at all.
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
More information about the Digitalmars-d-learn
mailing list