Difference between define_method and def method; end

Hello dear Rubyists.

It was suggested on the IRC channel that I try the ML for this
problem …

While looking at how to undefine a method, I found out that there is
a difference in how define_method and the def … end block works.
Example coming up:

Two classes to play with.

class Parent
def lol
puts “P: LOL”
end
end

class Child < Parent
# Commenting out the redefinition doesn’t help
def lol
puts “C: LOL”
end
end

test1.rb

c = Child.new
c.lol # => “C: LOL” or “P: LOL” if commented out
Child.class_eval { undef_method :lol }

Try to redefine method and call super.

class Child < Parent
def lol
print "LOL: "
begin
super
rescue NameError => e
puts e.to_s
end
end
end

c.lol # => “LOL: superclass method `lol’ disabled”

Then in test2.rb:

c = Child.new
c.lol # => “C: LOL”, or “P: LOL” if commented out.

Child.class_eval { undef_method :lol }

Try to redefine method and call super.

Child.class_eval do
define_method(:lol) { print "LOL: "; super }
end
c.lol # => “LOL: P: LOL”

Now … Why can I call super in the redefinition of the method using
define_method, and not using the def … end block? For me this seems
like an inconsistency. First I thought it was neat that I could not
call super in the method after using undef_method and redefining it
again, but then I found out I could using define_method.

As the comments state, I also tried to run the code with the
redefinition of the lol method in the Child class, but to no help.
The output is roughly the same (P instead of C obviously).

Anybody care to shed a little light on this?

On Tue, 31 Oct 2006, Rune H. wrote:

Hello dear Rubyists.

It was suggested on the IRC channel that I try the ML for this problem …

While looking at how to undefine a method, I found out that there is a
difference in how define_method and the def … end block works. Example
coming up:

Try to redefine method and call super.

class Child < Parent

you are not redefining the method here, you are redefining the class.
if you
simply redefine the method it does what you expect:

 harp:~ > cat a.rb
 class Parent
    def lol() puts "P: LOL" end
 end

 class Child < Parent
    def lol() puts "C: LOL" end
 end

 c = Child.new
 Child.class_eval { undef_method :lol }

 class Child  #< Parent
    def lol
      print "LOL: "
      super
    rescue NameError => e
        puts e.to_s
    end
 end

 c.lol


 harp:~ > ruby a.rb
 LOL: superclass method `lol' disabled

regards.

-a

On 31. okt. 2006, at 17:10, [email protected] wrote:

end
     print "LOL: "
     super
   rescue NameError => e
       puts e.to_s
   end
end

c.lol

harp:~ > ruby a.rb
LOL: superclass method `lol' disabled

That is actually the same output I had. My problem (and excuse me for
not
stating it clearly) is that if I use define_method after undef_method:

 Child.class_eval { undef_method :lol }
 c.lol # raises exception (of course)

 class Child; def lol() print "LOL: "; super end; end
 c.lol # raises exception (superclass method disabled)

 Child.class_eval { define_method(:lol) { print "LOL: "; super } }
 c.lol # prints "LOL: P: LOL"

So you see: defining the method using the def … end block raises an
exception if you call super after the method has been undefined, while
defining it using define_method does not. I expected it to either
raise or not
raise the exception in both cases (but do the same for both).

I hope that clarified it (although I’m not sure it did, as explaining
things
can be hard to do even in your native language).

… or am I still redefining the class using the class … end block?

Rune H. wrote:

   def lol() puts "P: LOL" end
   def lol
LOL: superclass method `lol' disabled

things
can be hard to do even in your native language).

… or am I still redefining the class using the class … end block?


Vennlig Hilsen / Regards
Rune H.

Hmm, very odd! You can get around this by doing something like this:

class Object
def supercall(meth, *args)
method_name = meth.to_s
current_class = self.class
m = nil
until m
raise NoMethodError if current_class == Object
current_class = current_class.superclass
if current_class.instance_methods.include?(method_name)
m = current_class.instance_method(method_name)
end
end
m.bind(self).call(*args)
end
end

You then replace the “super” keyword with a supercall(:foo) in your
example and it works. This is much slower though.

On 10/31/06, [email protected] [email protected] wrote:

coming up:

Try to redefine method and call super.

class Child < Parent

you are not redefining the method here, you are redefining the class.
[…]

Ara I am afraid that is not so :(, run this e.g.

class Parent
end

class Child < Parent
puts self.object_id
def one; puts “one” end
end
class Child < Parent
puts self.object_id
end
Child.new.one

<Ara's version of code snipped>
 harp:~ > ruby a.rb
 LOL: superclass method `lol' disabled

It does the same as OP’s code, I really feel this is strange.
Rune, on philiosophical grounds, I prefer the second behavior the super
method being available again, can you elaborate on why you prefer the
first?

Cheers
Robert


The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.

  • George Bernard Shaw

Robert D. wrote:

first?
I don’t necessarily prefer the first, I prefer them to behave the
same way.
Actually having the super method available makes more sense.

The reason I stumbled upon this is because I’m writing about
sandboxing and
would like to explain how you can supply “safe” versions of classes
in the
sandbox by “disabling” unsafe methods (of course it doesn’t help if
you can
simply redefine the method yourself, but it’s a first step). When
playing
around with undef_method and remove_method I found that remove_method
only
removes method defined in the class it self (and not derived
methods), while
undef_method prevents objects of the class from responding to the
method (as
is explained in ri Module.undef_method). And then I found this
inconsistency
in behavior.

While we’re on it: any good suggestions for how to supply “safe”
versions of
classes to the sandbox? Something like how Python’s Bastion module is/
was
supposed to work (it’s now deprecated, together with the RExec
module). I
guess the best would be to call remove_method on the unsafe methods
in the
classes they are defined, and hope that an attacker don’t redefine
the method
himself (which is hard to prevent).

On 11/1/06, Rune H. [email protected] wrote:

super
method being available again, can you elaborate on why you prefer the
first?

I don’t necessarily prefer the first, I prefer them to behave the
same way.
Actually having the super method available makes more sense.

I agree, I think consistent behavior would be preferable, not losing
the
super method seems also more POLS to me.
Now after all that talk :wink:

Great You Came Up With This , Rune!!!

Might this go away?

The reason I stumbled upon this is because I’m writing about

methods),
there was a thread about that, if you are interested it might pay to
search
the archives


Vennlig Hilsen / Regards
Rune H.


The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.

  • George Bernard Shaw

On Wed, 1 Nov 2006, Robert D. wrote:

puts self.object_id
end
Child.new.one

<Ara’s version of code snipped>

 harp:~ > ruby a.rb
 LOL: superclass method `lol' disabled

huh - i’d sworn that was the case… looks like you are right.

sorry about that!

-a

On 1. nov. 2006, at 18:05, Robert D. wrote:

Might this go away?
I stumbled upon it by pure coincidence … Should I report a RCR or
something like that?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs