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