Abstract functions in child classes

[Adam]

>> 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
instantiated.
>> 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
other
>> 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
here..
>> unless it throws a runtime exception for this case.. hmm.

>> So.. adding abstract to the class definition doesn't seem to gain
us
>> much.  You can argue, as Jonathan did that it's more consistent,
or
>> 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
already
>> 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
abstract.

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.