From: Jason Voegele <jason@...>
Date: 2002-05-02T23:10:32+09:00
Subject: RE: Scope of Singleton Classes

>> 3) Is caching methods like this (rather than relying on method_missing
> for
>> each invocation) a significant enough performance improvement to make
> it
>> worth it?
> 
> Because the method you define to "cache" ends up calling the #forward
> method, I can't see how this would be different than performance of
> calling #forward from method_missing.

After thinking about this a little more, I'm convinced that generating
methods at run time will be a significant performance enhancement.

What I'm actually building is a client-side CORBA ORB for Ruby.  The
ObjectProxy will be the client side "stub" and will utilize the Dynamic
Invocation Interface (DII) to forward requests to the CORBA object.  What
method_missing must do for each invocation is query the Interface Repository
to get meta-information about the CORBA object and the operation being
invoked (parameter and return types, etc.).  Rather than hitting the
Interface Repository for this information each time (a rather slow
operation), I'd like to generate a method that knows how to call the
operation directly after the first time it is invoked.  So method_missing
would actually look more like this:

# pseudo-code
def method_missing(operation, *args)
    op = lookup_operation(klass, operation) # slow
    class << self
        define_method(operation, args) do |*opargs|
            send_iiop_request(...)
        end
    end
end
I'd like to avoid the cost of looking up the meta-information in subsequent
calls.  So if I did something like this:

obj = ObjectProxy.new(some_object_id)
obj.foo
obj.bar
obj.foo

The second call to foo could avoid the dynamic lookup and call the method
directly.

So my question really boils down to: is there a way to do this using
define_method rather than eval?  Also, is there any documentation of
define_method and friends online?  My copy of Ruby in a Nutshell was stolen
along with my laptop on a trip to Toronto last week. :-/

Thanks, and sorry for the rambling :)
Jason Voegele