> LçÉettçËäº "erlercw / siu.edu" <erlercw / siu.edu>
> Aihe: Setting and getting methods and variables
> 
> 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.
> 
> 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.
>
> 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).
> 
> MethodHash#merge would be an easy way to do advanced things 
> similar to mixing in modules (although the current method of 
> actually mixing in modules works fine and should be kept).
> 
> MethodHash#delete would be an easy way to do 
> Object#remove_method; hash[:method] = nil should also work.  I 
> propose leaving two ways to do Object#undef_method: provide 
> Object#undef_method (or something with a better name like 
> #forget_method or #block_method) that will set the method in 
> the MethodHash to false (conceptually, Ruby looks at the 
> object's methods first, and false would make the point clear to 
> Ruby and programmers).  This will allow people to figure out 
> how to block a method just by looking at method names and also 
> allow a somewhat intuitive way of blocking to those who don't 
> like memorizing method names.
> 
> MethodHash#keys would do the same thing as the array-returning 
> methods (that list methods) do now.
> 
> This would make Ruby much less Java-like (verbose and no nice 
> features like #[] and #[]= outside of arrays).  It would remove 
> the need to learn which arcane incantation you need (and allow 
> for Ruby's designers not to have to waste time thinking up 
> names) for private instance methods compared to instance 
> methods (Do I use 'set' or 'define' here ?  Does the verb come 
> first or last ?  etc).  Plus, it would be, like blocks and 
> iterators, easier to learn and apply in Ruby than most other 
> languages.  It would also reduce the time I need to spend 
> looking in Pickaxe for method names.
> 
> I'm planning on making this an RCR, but I wanted to hear a bit 
> of criticism to help me shape the RCR.

What if that Object is a Hash or any other object that already 
implements [] and []= for other purposes? Or are you saying that
instead of:

foo = Object.new
foo.instance_variable_set :@bar, "BAZ"

One would write:

foo.instance_variable[:@bar] = "BAZ" 

(And not foo[:@bar] = "BAZ")?

Something simple, 

Object#iv
-and-
Object#method

E