Logan Capaldo
1/3/2006 11:11:00 PM
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