From: "David A. Black" <dblack@...>
Date: 2007-03-07T22:36:31+09:00
Subject: Re: object_* and instance_* methods

Hi --

On 3/7/07, Brian Candler <B.Candler@pobox.com> wrote:
> On Wed, Mar 07, 2007 at 10:07:01PM +0900, David A. Black wrote:

I didn't write what follows so I guess the quoting got hosed :-)

> > >> 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 know; I was just concerned that, with the references to soup and
things being half-implemented and so on, people could get the
impression that this was all being ascribed to some failing on the
part of Matz. If so, that would be a meta-impression; I definitely
know that you're not saying that :-)

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

So do I. self.class is definitely not a high point. And the biggest
problem is probably that it brought about the creation of the #type
method, which to this day, I believe, makes it harder than it should
be for people to get the type != class thing.

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

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.


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
   (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)