From: Pierre Barbier de Reuille <Pierre.Barbier_de_Reuille@...>
Date: 2006-03-27T17:49:23+09:00
Subject: Re: deciphering poignant guide chapter 4 example

john_sips_tea@yahoo.com a �crit :
[...]
>   
>> As you seem to come from the Python's world, you probably
>> know that Python's strings are immutable. And if you read a
>> little bit about why strings in Python are immutable, you will
>> see it's because they wanted to optimize the method lookup.
>>     
>
> I'll have to think about that. I don't see the connection between
> strings and method lookup. In Python code, you write a name(),
> and python works its way up the inheritance tree looking for
> the function definition. You can't call a method like:
>
> def my_func():
>     print "hi"
> foo = "my_func"
> foo()  # Trying to call my_func, but it fails.
>
> so I don't see the string/method-call connection you're
> referring to...
>
>   
Ok, so, internally, when you write :

obj.fct()

the language first has to find out if and where "fct" is in "obj". To do 
so, ruby will see "fct" as a Symbol and look for that symbol in "obj", 
and Python will see "fct" as a string and look for it in "obj".
Unlike C++ and Java, the method resolution is done entirely at runtime, 
so you have to use the *name* of the method to find it ! Remember that 
any single object may or may not have the method defined, whatever its 
class is !!!

If you prefer, these two statement are exactly equivalent :

obj.fct <=> obj.send(:fct)

The same equivalence in Python:

obj.fct <=>obj.getattr("fct")

Thus, in the dynamic languages, you need to keep a symbolic 
representation of the methods, whether as a symbol or as a string 
(symbol is more efficient, that's why Python's string are in fact 
symbols ...).
[...]


Hope that helped !

Pierre