Re: new method dispatch rule (matz' proposal)

On 6/14/07, Daniel Berger <[e-mail]> wrote:
> Rick DeNatale wrote:
>
> <snip>
>
> > My opinion is that the cure for this 'problem' is worse than the disease.
>
> I'd settle for a warning when run with -w. This code emits a warning
> when run with -w:
>
> # redef.rb
> class Foo
>     def bar
>        puts "hello"
>     end
>
>     def bar
>        puts "world"
>     end
> end
>
> redef.rb:6: warning: method redefined; discarding old bar
>
> But this does not:
>
> # redef2.rb
> class Foo
>     def bar
>        puts "hello"
>     end
> end
>
> class Baz < Foo
>     def bar
>        puts "world"
>     end
> end
>
> Is there any way to make the 2nd case emit a warning without major
> changes to core Ruby?

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.

 Also what should happen in a case like this:

class Foo
end

class Baz < Foo
  def bar
     puts "world"
  end
end

class Foo
   def bar
       puts "hello"
   end
end

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.


-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/