Abstract functions in child classes

[Regan Heath]

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.

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/