Abstract functions in child classes

Adam Adam at anizi.com
Fri Dec 2 10:02:21 PST 2011

>> Well, I believe I understand your argument and I admit that I did
find it
>> odd that the error was not detected until the class was
>> But, once I thought about it I understood why this is the case,
and I
>> believe you understand it as well.  I also understand that you'd
rather it
>> wasn't the case.  I think the only area of disagreement here is
how much
>> of a problem this is likely to be.

>> Using the library example you gave, and assuming 'basic' testing
of the
>> exported classes etc, you would discover the problem immediately.
No harm
>> done.  In most other cases, you're either the producer of the
parent, or a
>> consumer of the immediate child and you'll discover the problem
>> immediately.  So, again no harm done.

>> The only remaining case (I can see) is the one I mentioned in my
>> thread/reply.  That of the end user swapping out the parent
library, in
>> which case your library is not recompiled and D can't help you
>> unless it throws a runtime exception for this case.. hmm.

>> So.. adding abstract to the class definition doesn't seem to gain
>> much.  You can argue, as Jonathan did that it's more consistent,
>> provides a visual clue to the programmer.  But, the flip side is
that it
>> can be irritating to have to add it in the cases where it's
>> obvious to anyone reading the code - I have moments like that
writing C#,
>> even with good intelisense and good auto code generation.

(I really need to get a client for this - I just had to manually
copy out your message and RegEx it to add the little >> marks)

Well, specifically, here's what it *does* give you:
It means that a class *not* marked as abstract is not intended by
the programmer to be abstract (equivalent to explicitly marking
something as nonabstract). If we accept that the default class
declaration (class X {}) is non-abstract, then we probably don't
need to consider explicit specification of non-abstraction.
It means that a class *marked* as abstract is intended to be

The difference is that the compiler can then decide at the
definition of a class - where this error belongs - if a Class
actually conforms to its contract of being abstract / concrete.

No harm is done if sufficient testing in place, but it still puts
the onus in *some* (probably quite specific or rare) circumstances
on the user of my class, because it's feasible for my class to have
been previously valid.

On the other hand, I should not require a unittest just to ensure
that my class is the same class it was between some (potentially
unknown) change. That's not to say that I shouldn't test, but I
shouldn't have to for this one, particular case.

But D does not allow me to explicitly make it clear that my class is
intended to be concrete, and it's relying on usage, rather than
definition, for this information.

More information about the Digitalmars-d-learn mailing list