From: Daniel DeLorme <dan-ml@...42.com>
Date: 2007-03-07T23:47:34+09:00
Subject: Re: object_* and instance_* methods

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

Forcing all those methods to have an object_ or instance_ prefix is 
self-evidently nonsense. Therefore being a metaprogramming method 
*cannot* be the basis of using those prefixes.

But while I don't like the sound of "object_is_a?", I still like the 
sound of "object_class" and "object_method". And I am starting to 
realized that the reason is those methods represent /attributes/ of the 
object while "is_a?" or "taint" are /actions/. In the case of 
attributes, "object_" is not merely a prefix but an adjective to the 
ambiguous noun "id". Same for "class" of "method". It makes the methods 
sound natural, unlike slapping a prefix in front of an action verb. If I 
follow that line of reasoning, object_send and instance_send may be bad 
ideas. Unless we accept that some exceptions are inevitable, like 
instance_variable_[gs]et.

Don't we just love semantics? ;-)

Daniel