[CHALLENGE] better alias_method

[Logan Capaldo]

Like is Haskell you'd have to explictily state it's recursive. So for
instance I'm suggesting:

class A
def x; "x"; end
end

class B < A
def x; x.upcase; end
end

Ordinarily B#x would recurse (and be an infinite loop). But not so in
my suggestion. So the above would work and rather you'd have to tell
it esspecially if recursion were desired, something like:

I'm pretty sure this would be impossible (also you are thinking of
ML, not Haskell (Haskell's defs are recursive by default, it is in ML
where you have to say let rec (and Lisp/Scheme as well) to define a
recursive function) in ruby since ML and friends find those functions
lexically at compile time. I guess the parser could do the equivalent
of s/#{current_method}/super/g on the body of the function, but that
just makes it alternate syntax and doesn't solve this problem.

class A
def x(n); n - 1 ; end
end

class B < A
def_rec x(n)
x == 1 ? 1 : n + x(x(n)) # err... x(super(n))
end
end

Now in this case how do you call A#x from B#x if you need to? We would
still need to have #super as shown in the comment.

Hmm... better yet, you could do without super altogther and also not
need the special def_rec if we had a special method that meant "this
method", maybe #this. So:

class B < A
def x(n)
x == 1 ? 1 : n + this(x(n))
end
end

Forth has this, it's called "recurse" there. (also Joy has a whole
slew of words for recursion with anonymous functions).

 

[Rick DeNatale]

the primary reason to use aliases is not to simply have another handle on
names - but override or wrap a method for instance.

Here's a sketch which generalizes this a little and adds a module
method sort of like private, which syncronizes the next method to be
defined.

I'm not sure how you'd make synchronized work like private and make
all subsequent methods synchronized. The issue is figuring out when to
turn it off when the module definition is closed.

rick@bill:/public/rubyscripts$ cat syncwrapper.rb
class Module

alias_method "__method_added__", :method_added
def method_added(meth_name)
if @synchronize_new_method
@synchronize_new_method = false
synchronize_method(meth_name)
end
__method_added__(meth_name)
end

def synchronize_method(meth_name)
module_eval {
alias_method "__#{meth_name}__", "#{meth_name}"
}
module_eval <<-code
def #{meth_name}(*a, &b)
p "Synchronized"
__#{meth_name}__(*a, &b)
end
code
end

def synchronized(*meth_names)
@synchronize_new_method = meth_names.empty?
meth_names.each do |meth_name|
synchronize_method(meth_name)
end
end
end

class C

def fee
42
end

synchronized
def fie
43
end

def foe
44
end

def fum
45
end

synchronized :foe
end

p C.new.fee
p C.new.fie
p C.new.foe
p C.new.fum

rick@bill:/public/rubyscripts$ ruby syncwrapper.rb
42
"Synchronized"
43
"Synchronized"
44
45

 

[Rick DeNatale]

The solution to this problem will actually let alias_method fall into
disuse faster, since we don't need to use alias_method directly to wrap or
override an old method anymore.

But the point is that although you can 'hide' alias_method behind a
DSL or a layer of metaprogramming, having it as a language feature is
invaluable in creating DSLs or doing metaprogramming

Two more reasons for having aliased methods in Ruby is for comfort of
programmers coming from other languages, and to efficiently provide
identical methods some of which might be overriden in subclasses, and
show which shouldn't be (like Object#==, and Object#===)

For an example of the first aliasing Enumerable#collect and
Enumerable#map gives Smalltalk programmers a familiar name for the
method, while map might be more familiar to others.

For the second,

 

[Ken Bloom]

the show stopper for me is the fact that define_method cannot define methods
that take blocks - so your approach loses them during the alias process.

i remember that define_method will soon have the ability to define methods
that take blocks do you know if that's in 1.8.5 or the 1.9 branch?

Having established that 1.9 has this feature, my #override method (and
also Facets' #wrap_method should Just Work (TM) in 1.9 with defining
methods that take blocks.

--Ken