From: Wayne E. Seguin [mailto:wayneeseguin / gmail.com] :
# That makes complete sense. 

careful. me thinks define_method is verry different from normal ruby methods,
 a. it flattens scope. variables just creep inside
 b. it does not check for arguments

ergo, i'd prefer define_method be renamed to define_method! 

i suggest define_method should be documented clearly. it could hang nubies, like me :)

module_eval-ing may be closer to ruby methods.

eg,

C:\family\ruby>cat test.rb
a = 1
class C; end
C.class_eval {define_method(:show_a) {a}}

# this will not err; define_method methods do not check arguments!
puts C.new.show_a(1)

# just to show difference...
class C
   def show_a2
      a
   end
end

# this will err as usual; i just put a rescue to let prg continue
puts C.new.show_a2(1) rescue puts "wrong number of args !!"

# I think module_eval is a closer match to normal methods
s = %q{def show_a(); a ; end}
C.module_eval(s)

# vars will not creep
puts C.new.show_a() rescue puts "undefined a !!"
# and args will be checked
puts C.new.show_a(1) rescue puts "wrong number of args !!"

C:\family\ruby>ruby test.rb
1
wrong number of args !!
undefined a !!
wrong number of args !!

C:\family\ruby>


kind regards -botp