Re: new method dispatch rule (matz' proposal)

Rick DeNatale wrote:
> I'm not sure it should. Overriding a method is perfectly natural,
> sometimes you call super as part of that,when you are augmenting the
> inherited method, but sometimes you ARE replacing it and that's fine.

Sometimes but IMHO rarely. If the parent class has some implementation, 
subclasses are more likely to augment/supplement that implementation 
rather than discard it completely. IMHO discarding the parent method has 
a strong risk of breaking stuff if the implementation of that parent 
method ever has to change.

However I have to admit that it could get complicated when method 
aliasing is used instead of super, like rails does a lot.

> Note that this is a temporal ordering, the code need not appear in the
> same file, for example the bar method might be added to the base class
> foo in a gem.
> 
> To make it more explicit, should Ruby examine all existing
> superclasses AND subclasses AND including classes when changing a
> class/module?
> 
> What about singleton methods and classes?
> 
> There be dragons!
> 
> There's no magic bullet to warding off changes due to changing
> ancestors and descendants, the best one can do is to be aware of what
> CAN happen, and have a good set of regression tests to detect
> problems.

It might be tricky in some edge cases but a solution doesn't need to be 
a magic bullet in order to be useful. Such a warning would have been 
useful to me when I was a newbie and wondering why the module I was 
including in a class wasn't overriding the methods I wanted it to.

Daniel