Re: Why does def return nil?

On Oct 8, 2007, at 06:28 , Jonas Pfenniger wrote:

> Another argument against using Symbols is that you will grow the
> symbol hash table, even if you only use a fraction of them. Since that
> table can't be garbage-collected, it can be quite problematic.

You're doing that simply by defining the method in the first place.  
Symbol values (at least used to) map directly to method names, which  
explains why you can't do things like "".intern.

As for returning a method object... since we don't have 1st class  
access to method dictionaries and the like, I don't see the value in  
returning a method instance. First, it'll be a copy of the real  
method, so it'll expend memory that in a lot of cases is simple  
bloat. Last time I counted, rails had roughly 500 requires and who  
knows how many methods defined... Imagine if they all created copies  
of themselves.

Second, as David pointed out, instance methods would be  
UnboundMethods, so you can't do much useful with it in the first  
place (at least, in terms of the OP's original context and the  
RCR's)... what is memoize gonna do with an UnboundMethod? Not too  
much if I'm not completely off track (and I'm on enough cold medicine  
that I really can't rule that out).