On Dec 11, 2011, at 11:17 PM, Grary S. wrote:
Yes, I understand your proposed approach.
I think your approach is better than the one I was playing with, because
bit lazier and more permissive, for example, in the case the child does
not override every method ‘required’ by the parent, they could still use
it to some desired effect.
Yes. In fact, in this case the example didn’t make sense, because I just
exchanged one runtime error for the other. But in many cases you
actually have some benign good value which you could use (in addition
you could print a warning as a reminder that the method should be
redefined) in that method ‘stub’.
Yet, under the alternative approach I propose, not even that is required
– the documentation suggests it or shared tests require it.
Testing is a good point, actually. I find that when you require mocks or
stubs in your tests those instances often arise exactly when there are
requirements that are difficult to express, or are expressed only by
programming-by-contract type of comments/documentation (e.g., base
classes must implement this method, passed in argument must provide a
certain property etc.).