undef_method and method lookup algorithm

[Xavier Noria]

Descriptions of the method lookup algorithm normally describe a path
from the very eigenclass of an object up to the resolution of
method_missing. For example check Flanagan & Matz, pages 258--259.

Until now I visualized entities having pointers to classes and
modules, who had tables of method names. So my idea was that, for
example, resolving a method invoked on some object may eventually
follow the pointer to its class, and look at its method table as
defined at that moment. If the method is founded there it is executed.
Fine.

But I just realized there's undef_method, that prevents looking up the
hierarchy:

class C
def croak; end
end

class D < C
undef_method :croak
end

C.new.corak # fine
D.new.croak # NoMethodError

Hence, I guess the method lookup algorithm does a bit more of work,
there's going to be a black list to check or something like that where
undef_method moves stuff.

Anyone?

 

[Calamitas]

[Note: parts of this message were removed to make it a legal post.]

Descriptions of the method lookup algorithm normally describe a path
from the very eigenclass of an object up to the resolution of
method_missing. For example check Flanagan & Matz, pages 258--259.

Until now I visualized entities having pointers to classes and
modules, who had tables of method names. So my idea was that, for
example, resolving a method invoked on some object may eventually
follow the pointer to its class, and look at its method table as
defined at that moment. If the method is founded there it is executed.
Fine.

But I just realized there's undef_method, that prevents looking up the
hierarchy:

class C
def croak; end
end

class D < C
undef_method :croak

This should be more or less equivalent to this:

def croak
raise NoMethodError, "..."
end

end

C.new.corak # fine
D.new.croak # NoMethodError

Hence, I guess the method lookup algorithm does a bit more of work,
there's going to be a black list to check or something like that where
undef_method moves stuff.

Ruby inserts a dummy method definition in the class where the undef is
performed, flagging it as undefined. All the method lookup algorithm has to
do is check that flag.

The method definition above is not completely equivalent because you can
alias it, get it as a method object and such, but it should convey the basic
idea.

Actually, there's an explanation of this in the Pickaxe.

Peter

 

[Xavier Noria]

Actually, there's an explanation of this in the Pickaxe.

Of the implementation?

 

[Calamitas]

[Note: parts of this message were removed to make it a legal post.]

Of the implementation?

Seems I slightly misremembered. A comparable technique is used when a method
is declared private in a subclass of the class where the method is defined,
which *is* described in the Pickaxe (p394 in Pickaxe 2).

Peter