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