> Lähettäjä: "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