>> 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.
