From: Trans <transfire@...>
Date: 2007-03-08T06:36:10+09:00
Subject: Re: object_* and instance_* methods



On Mar 7, 9:47 am, Daniel DeLorme <dan...@dan42.com> wrote:
> David A. Black wrote:
> > And that's why I'd rather not get "meta" about it.  It seems to me
> > that determining categorization for each method cannot be *better*
> > than determining what the method does and naming it based on that. In
> > particular, getting into an open-ended debate about what is and isn't
> > metaprogramming in Ruby is, I think, unpromising and wasteful.
>
> I'm starting to see your point. If we follow to its extreme the logic of
> having a consistent prefix for all metaprogramming methods, we wind up
> with a huge number of methods that can be considered to be
> metaprogramming. Taking Object.instance_methods and removing aliases and
> methods meant to be overridden, I get:

> class
> extend
> freeze
> frozen?
> instance_eval
> instance_of?
> instance_variable_get
> instance_variable_set
> instance_variables
> is_a?
> method
> methods
> object_id
> private_methods
> protected_methods
> public_methods
> respond_to?
> send
> singleton_methods
> taint
> tainted?
> untaint

Lets back up a second, these are "meta" because they are considered
"critical", right? The foremost reason for adding a prefix is simply
to make their name more uniq, so as be unlikely to clash with user-
defined method names. Most of these already fit that criteria. Any
that start with instance_ or object_ is uniq enough. And I would think
any of these having a punctuation mark is uniq enough as well. That
leaves:

> class
> extend
> freeze
> method
> methods
> private_methods
> protected_methods
> public_methods
> send
> singleton_methods
> taint
> untaint

Now I've always felt the methods, public_methods, private_methods and
protected_methods and singleton_methods were quite wasteful. One
method would suffice for all five, this has been discussed before. And
if we went ahead and did that and called that method #object_methods
and along with it had #object_method. Then all those are good to go
too. Leaving:

> class
> extend
> freeze
> send
> taint
> untaint

Now we all seem to agree that it at least makes sense to say
object_class to go along with object_id. And while I know there's
resistance to object_send (and instance_send) it makes a heck of a lot
of sense mnemonically. So if we could just go with that then there are
only four methods left:

> extend
> freeze
> taint
> untaint

I now sure about extend, but as for the last three. if these are
really critical then I'd take Daniel's idea about "action" to heart
and add a ! to them. They pretty much embody the idea of "danger"
methods.

  freeze!
  taint!
  untaint!

There may be few methods forgotten here, and they can be considered,
but we're not after perfection --for that these methods would probably
have to be moved out of Object. But we at least gain a system much
improved.

T.