From: Logan Capaldo <logancapaldo@...>
Date: 2006-01-04T08:11:11+09:00
Subject: Potential RCR: method_missing convention, opinions?

I was pondering the other day, and an idea regarding "method_missing"  
came to me. I don't want to make this a full-fledged RCR just yet  
because I want some feedback first, I feel like this is one of those  
ideas that their may be something blatantly untenable about that I've  
missed but who knows.

Basically my suggestion is this. Rather than method_missing  
performing the task of a message when we wish it to dynamically  
respond to messages, have it return a Proc/Method/something that has  
a call method. Then the runtime would automatically call this Method/ 
Proc/etc. with the arguments that were originally passed in, assuming  
of course that thats why method_missing was called. Now why do this  
you may ask? Well, my rationale is this, we can unify the responses  
to #method, #respond_to?, etc.

No longer would you have to override respond_to? if you overloaded  
method_missing, it would call method_missing and see if it got back  
an object, if it did, it would return true. Similarly with #method,  
it could return the object returned by method_missing if the method  
did not already exist.

Pros:
- No more worrying about your custom dispatching in potentially 3  
different places, you just write the code once.
Cons:
- Increased complexity of method calling semantics
- Not backwards-compatible at all. (This is a biggee).

So any thoughts? Anything wrong with this that I missed?

And just in case I've been unclear, an example:

% cat example.rb
class Example
    def method_missing(name, *args)
          lambda { puts "Method  #{name} called." }
    end
end

example = Example.new
example.hola
if example.respond_to?(:hello)
    puts "Example knows how to say hello"
end


% ruby example.rb
Method hola called.
Example knows how to say hello