Abstract functions in child classes
regan at netmail.co.nz
Fri Dec 2 09:52:32 PST 2011
On Fri, 02 Dec 2011 17:43:04 -0000, Adam <Adam at 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.
Using Opera's revolutionary email client: http://www.opera.com/mail/
More information about the Digitalmars-d-learn