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.
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
···
On Wed, Sep 24, 2008 at 2:37 AM, Xavier Noria <fxn@hashref.com> wrote:
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
···
On Wed, Sep 24, 2008 at 11:08 AM, Xavier Noria <fxn@hashref.com> wrote:
> Actually, there's an explanation of this in the Pickaxe.