From: ara.t.howard@... Date: 2006-09-09T01:17:46+09:00 Subject: Re: BEST alias_method Re: [CHALLENGE] better alias_method On Sat, 9 Sep 2006, Jason Nordwick wrote: > The best alias_method methods would be one that didn't exist. > (1) It encourages breaking of naming conventions since at times two functions > get defined, one with the convension and one without, (see hash.merge! and > hash.update), and I really liked the convention where mutatations have bangs > at the end. > > (2) This one function double the complexity of learning to read ruby. Now I > don't just have to know what hash.update does, but also that hash.merge! is > the same thing. And when individual developers start adding aliases to > buildins things get ever worse. Array.lower isn't necessary when Array.first > and Array[0] are both as short or shorter and just as descriptive. > > Alaises increase complexity and really are one of Ruby's biggest dislikes for > me. the primary reason to use aliases is not to simply have another handle on names - but override or wrap a method for instance. require 'sync' class Module def ex m module_eval{ include Sync_m alias_method "__#{ m }__", "#{ m }" } module_eval <<-code def #{ m } *a, &b synchronize{ __#{ m }__ *a, &b } end code end end class C def foobar 42 end ex :foobar end if you do much metaprogramming and/or dsl contruction you find, in a matter of seconds, that alias_method is essential. i think most people find the declarative style of class methods as syntax (think 'attr', 'has_and_belongs_to_many', etc) to be one of ruby's best features. unfortunately it oftern hinges on alias_method which has issues if a cycle is setup. regards. -a -- what science finds to be nonexistent, we must accept as nonexistent; but what science merely does not find is a completely different matter... it is quite clear that there are many, many mysterious things. - h.h. the 14th dalai lama