# Undef\_method and method lookup algorithm

**URL:** <https://www.ruby-forum.com/t/undef-method-and-method-lookup-algorithm/149361>\
**Category:** Ruby\
**Created:** [September 24, 2008, 2:38am UTC](https://www.ruby-forum.com/t/undef-method-and-method-lookup-algorithm/149361 "2008-09-24T02:38:22Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![fxn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/77aa72/32.png) [@fxn](https://www.ruby-forum.com/u/fxn)\
**Post date:** [September 24, 2008, 2:38am UTC](https://www.ruby-forum.com/t/undef-method-and-method-lookup-algorithm/149361/1 "2008-09-24T02:38:22Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![fxn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/77aa72/32.png) [@fxn](https://www.ruby-forum.com/u/fxn)\
**Post date:** [September 24, 2008, 9:42am UTC](https://www.ruby-forum.com/t/undef-method-and-method-lookup-algorithm/149361/2 "2008-09-24T09:42:39Z")

</div>

On Wed, Sep 24, 2008 at 2:37 AM, Xavier N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> 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

---

<div class="post-metadata">

**Author:** ![fxn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/77aa72/32.png) [@fxn](https://www.ruby-forum.com/u/fxn)\
**Post date:** [September 24, 2008, 11:09am UTC](https://www.ruby-forum.com/t/undef-method-and-method-lookup-algorithm/149361/3 "2008-09-24T11:09:00Z")

</div>

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

Of the implementation?

---

<div class="post-metadata">

**Author:** ![fxn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/77aa72/32.png) [@fxn](https://www.ruby-forum.com/u/fxn)\
**Post date:** [September 24, 2008, 8:19pm UTC](https://www.ruby-forum.com/t/undef-method-and-method-lookup-algorithm/149361/4 "2008-09-24T20:19:57Z")

</div>

On Wed, Sep 24, 2008 at 11:08 AM, Xavier N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > Actually, there’s an explanation of this in the Pickaxe.
> 
> 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
