From: Csaba Henk <csaba@..._for_avoiding_spam.org>
Date: 2005-01-16T19:11:17+09:00
Subject: Re: Setting and getting methods and variables

On 2005-01-15, erlercw@siu.edu <erlercw@siu.edu> wrote:
> Object#instance_variable_set
> Object#instance_variable_get
> Object#methods
> Module#define_method
> Module#remove_method
> Module#undef_method
>
> and all the other similar methods suffer from being scattered 
> through several classes and naming inconsistencies.  
> #instance_variable_set is not only noun-verb, the opposite of 
> most method names, set is also different than define.  Also, 
> what's the difference between remove and undef ?  It's not easy 
> to tell on first glance and the help at ruby-doc.org is a bit 
> misleading.
>
> The main problem is that it seems like a bunch of hackish 
> workarounds that were added after the language was designed.  
> Java needs things like utility classes and long, wordy names, 
> because it was badly designed.  Ruby doesn't need to suffer the 
> same problems.

Either way, I don't feel these method names as problematic as they
should be changed.

> I propose a more streamlined way of changing methods and 
> instance variables on the fly: treat them like hashes.  This 
> doesn't have to affect the inner workings of Ruby, just the 
> programmer's interface to Ruby.

These are quite sugared away from sight by the keywords one usually uses
to perform these actions. In everyday codig you rarely get to the point
where you need to use these explicitly. In these cases, I don't feel the
usage of the above being a pain.

>
> For instance, object_or_class.private_instance_methods should 
> return a reference to the object or class MethodHash.  This 
> will allow easily adding new methods or getting old methods 
> without obscure incantations.  The same kind of things could be 
> done with instance and class variables (perhaps with a normal 
> Hash or VariableHash).
[snip]
> MethodHash#keys would do the same thing as the array-returning 
> methods (that list methods) do now.

Do I understand correctly that you propose a proxy hash for modifying
the object in the above mentioned ways? If so, that seems to be
non-orthogonal, and quite an intrusion to Ruby internals. Let the object
take care of itself. It's a simple idea, and ruby owes its flexibility
for keeping things simple.

> languages.  It would also reduce the time I need to spend 
> looking in Pickaxe for method names.

Why don't just use the method name completion feature of irb?

Csaba