From: Brian Candler <B.Candler@...>
Date: 2007-03-07T23:02:51+09:00
Subject: Re: object_* and instance_* methods

On Wed, Mar 07, 2007 at 10:36:31PM +0900, David A. Black wrote:
> >Matz *could* separate this all out:
> >
> >  class Object < BasicObject
> >    include Kernel
> >    include Reflection
> >    ... etc
> >  end
> >
> >But then, you still wouldn't get any benefit unless you explicitly created
> >your new objects under BasicObject rather than Object, so there's not much
> >practical benefit.
> 
> There must be a way (though I'm multitasking too much right now to
> figure it out) to do something like create your own modules that
> consist of methods that already exist in other modules. Or something.
> That would be kind of interesting.

Hmm. Clearly this sort of stuff could go into a module; then anything which
is interested in reflections could do, say,

    def process(a)
      a.extend Reflection
      a.instance_methods.each { ... }
      ...
    end

Unfortunately, this causes a permanent change in the object being reflected
upon - an unintended Heisenberg-like side-effect.

However, suppose you could temporarily add a module:

    def process(a)
      b = a.insert Reflection
      b.instance_methods.each { ... }
      ...
    end

That would give an easy API, less cumbersome than Meta.instance_methods(a),
but not pollute the general method namespace of the object. Even better,
because the Reflection module was just inserted, when there is a name clash
then the method in Reflection will take precedence (e.g. b.class where a
already had overridden 'class')

I think this could be implemented using a proxy object / delegator.

But actually, there's no need to pass any method calls through. You could
just have a Reflector object:

    def process(a)
      b = Reflector.new(a)
      b.instance_methods.each { ... }
      ...
    end

B.