On Fri, 02 Dec 2011 17:43:04 -0000, Adam <a...@anizi.com> wrote:
I grant you that I should test it, and I never said otherwise. If I'm attacking a strawman, it's the same one that was just put in front of me as a misinterpretation of my argument.
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.
Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
