# Potential RCR: method\_missing convention, opinions?

**URL:** <https://www.ruby-forum.com/t/potential-rcr-method-missing-convention-opinions/89145>\
**Category:** Ruby\
**Created:** [January 4, 2006, 12:11am UTC](https://www.ruby-forum.com/t/potential-rcr-method-missing-convention-opinions/89145 "2006-01-04T00:11:35Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Logan\_C](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/e47774/32.png) [@Logan\_C](https://www.ruby-forum.com/u/Logan_C)\
**Post date:** [January 4, 2006, 12:11am UTC](https://www.ruby-forum.com/t/potential-rcr-method-missing-convention-opinions/89145/1 "2006-01-04T00:11:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Logan\_C](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/e47774/32.png) [@Logan\_C](https://www.ruby-forum.com/u/Logan_C)\
**Post date:** [January 4, 2006, 3:35pm UTC](https://www.ruby-forum.com/t/potential-rcr-method-missing-convention-opinions/89145/2 "2006-01-04T15:35:05Z")

</div>

Logan C. wrote:

> 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?

Hmmmm … an interesting idea. It is possible to provide this in a  
backwards compatible fashion too. Create a new method (say  
“replacement\_lambda”) that returns nil for Object and rewrite  
method\_missing and respond\_to? to use check for a replacement\_lambda.  
If one is not found, then just perform the original logic.

Somethind like this …

* * *

module Kernel  
def replacement\_lambda(sym)  
nil  
end

alias original\_method\_missing method\_missing

def method\_missing(sym, \*args, &block)  
if lamb = replacement\_lambda(sym)  
lamb.call(sym, args, block)  
else  
original\_method\_missing(sym, args, block)  
end  
end

alias original\_respond\_to? respond\_to?

## def respond\_to?(sym) replacement\_lambda(sym) || original\_respond\_to?(sym) end end

I don’t particularly like the name “replacement\_lambda”, and I’m still  
deciding if I like the extra complexity or not. But an interesting idea  
nevertheless.

–  
– Jim W.

---

<div class="post-metadata">

**Author:** ![Logan\_C](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/e47774/32.png) [@Logan\_C](https://www.ruby-forum.com/u/Logan_C)\
**Post date:** [January 4, 2006, 6:13pm UTC](https://www.ruby-forum.com/t/potential-rcr-method-missing-convention-opinions/89145/3 "2006-01-04T18:13:40Z")

</div>

“Jim W.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote in message

> Hmmmm … an interesting idea. It is possible to provide this in a  
> backwards compatible fashion too.

+1.

Given Jim’s way of retaining backward compatibility this would be good.

Which methods are affected? method\_missing, respond\_to?, method …

I guess things that enumerate methods (e.g. #methods, #instance\_methods)  
could not be covered.

---

<div class="post-metadata">

**Author:** ![Logan\_C](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/e47774/32.png) [@Logan\_C](https://www.ruby-forum.com/u/Logan_C)\
**Post date:** [January 4, 2006, 11:47pm UTC](https://www.ruby-forum.com/t/potential-rcr-method-missing-convention-opinions/89145/4 "2006-01-04T23:47:28Z")

</div>

On Jan 4, 2006, at 9:35 AM, Jim W. wrote:

> def respond\_to?(sym)  
> replacement\_lambda(sym) || original\_respond\_to?(sym)  
> end  
> end

Minor suggestion, I would flip that around, since it would probably  
A) be faster in the common case and B) consistent with current  
behavior. (If you call a method that something #respond\_to?s why are  
you gonna go through the extra dynamic dispatch.)

Other than that, I like how you managed to keep it backwards  
compatible and in pure ruby no less.