From: "Ara.T.Howard" <Ara.T.Howard@...>
Date: 2005-09-15T12:51:58+09:00
Subject: Re: params v.s. @params in rails?

On Thu, 15 Sep 2005, Neville Burnell wrote:

>>> From: Ara.T.Howard [mailto:Ara.T.Howard@noaa.gov]
>>> Sent: Thursday, 15 September 2005 1:22 PM
>>> To: ruby-talk ML
>>> Subject: Re: params v.s. @params in rails?
>>>
>>>     def method_missing(m, *a, &b)
>>>       idx = FIELDS.index m.to_s
>>>       return self[idx] if idx
>>>       super
>>>     end
>>>
>>> this routes through method_missing each time, which is expensive
>
> Intuitively it sounds expensive, because [I imagine] ruby needs to traverse
> then inheritance tree for the object, but in a simply case like your example
> is it still expensive, ie, is method_missing much more expensive than any
> other call ?

no.  it is just a method.  it's pretty easy to tell what happens from eval.c:

...
     /* is it in the method cache? */
     ent = cache + EXPR1(klass, mid);
     if (ent->mid == mid && ent->klass == klass) {
         if (!ent->method)
             return method_missing(recv, mid, argc, argv, scope==2?CSTAT_VCALL:0);
         klass = ent->origin;
         id    = ent->mid0;
         noex  = ent->noex;
         body  = ent->method;
     }
...

it probably isn't an issue in this simple example but if you were, say,
scanning a ten thousand things to determine an index then you be a winner.  it
definitely would require being able to do some sort of caching to make defining
the method worth bothering.  i was just trying to show how you could have
something like 'price' work without it actually being 'defined' anywhere.
rails leverages ruby to the hilt with things like this.

cheers.

-a
-- 
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze.  --Nagarjuna
===============================================================================