Calamitas
9/24/2008 7:42:00 AM
[Note: parts of this message were removed to make it a legal post.]
On Wed, Sep 24, 2008 at 2:37 AM, Xavier Noria <fxn@hashref.com> wrote:
> 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