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

On Wed, Mar 07, 2007 at 10:07:01PM +0900, David A. Black wrote:
> >> Woh! Now you're undermining the very reasons for doing this. If we all
> >> go willy nilly naming these things whatever we want we'll be in a
> >> worse can of soup thatn we were to begin with.
> >
> >I was just trying to make something which might be more palatable to the 
> >OP.
> >
> >If I understand rightly, he would rather use foo#object_class,
> >foo#object_send, foo#object_method etc. as a way of lexically identifying
> >these methods as "meta programming methods". I showed how he could 
> >implement
> >exactly what he asks for, where he wants it, without demanding changes to
> >the core Ruby language.
> >
> >However I agree with you - explicit reflections (which take an object as an
> >argument, rather than being methods on all objects) are probably a better
> >idea, to avoid the clutter.
> >
> >I think the argument is moot unless Matz decides to go this way in a later
> >version of Ruby; otherwise we'll still have method soup anyway :-)
> 
> But we don't.  The method names in Ruby are hand-crafted with great
> care, and they show it.  Also, when there are soup-like tendencies,
> Matz is eager and happy to discuss them.
> 
> (I see the smiley but I'm concerned that the drift of this thread
> could be seen as: Matz botched the method-naming thing, so we have to
> intervene and figure out how to fix it.)

No, that wasn't intended at all.

I'm not arguing that the methods are badly named, although I sympathise with
the argument that #class awkwardly clashes with the 'class' keyword.

By "soup" I mean that even an empty object has a zillion methods inherited
from Object and Kernel. I don't dispute there are good reasons for each one;
e.g. if you had to write "$stdout.puts" instead of "puts", or
"Kernel.require 'foo'", those would be off-putting. All I'm saying is that
objects will always have these zillion methods, unless Matz decides to
modularise it, so adding a few more (like extra reflection methods under
your own naming scheme) wouldn't make any difference.

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.

Regards,

Brian.