Re: new method dispatch rule (matz' proposal)

Daniel DeLorme wrote:
> David Flanagan wrote:
>> In Ruby 1.8, we can write code like this:
>>
>> class Test
>>   def initialize(greeting)
>>     @greeting = greeting
>>     @greeter = lambda { |x| puts "#@greeting #{x}" }
>>   end
>>
>>   def greet(x)
>>     @greeter[x]
>>   end
>> end
>>
>> t = Test.new("hello")
>> t.greet("world")
>>
>> In this code, the instance variable @greeter refers to a local 
>> function that is completely hidden from subclasses and cannot be altered.
> 
> class Test2 < Test; end
> t2 = Test2.new("hello")
> t2.greet("world") #=> "hello world"
> 
> How is this hidden from subclasses? Or did I miss something?
> 
> But this touches on an idea I was thinking about recently... how about 
> giving a warning when a subclasses overrides a method and doesn't use 
> "super"? IMHO in 99% of cases if you override a method you should call 
> super. In the other 1% of cases you could use an idiom like "super if 
> false" which makes it very clear when reading the code that we are 
> (dangerously) skipping the normal inheritance chain. It solves the same 
> problem as the new method dispatch rule but for *both* public and 
> private methods, while still leaving the programmer freedom to override 
> private methods if he knows what he's doing. Comments?
That ends up looking a lot like a magical side-effect to me.  Besides, I 
don't think the assumption (that you should often be calling super) 
necessarily valid.

What it sounds to me like you're pining for is the "override" keyword 
from C#.  I guess an equivalent implementation in Ruby might be for 
methods defined with "def" to pop a warning when they redefine a 
superclass method, and to introduce a "redef" keyword to do specifically 
that.

Not sure I like the look of it (introducing new keywords, bad), but I 
think it would fit the bill here.

-- 
Alex