On 28 Mar 2008, at 21:06, Daniel Berger wrote:
>
>
> On Mar 28, 11:21 am, "s.ross" <cwdi... / gmail.com> wrote:
>> On Mar 28, 2008, at 9:19 AM, ts wrote:
>>
>>> Park Heesob wrote:
>>>> So ruby is never fast but flexible language :)
>>
>>> Well I can give you another example of "premature" optimisation, but
>>> for 1.9
>>
>>> [ruby-bugs:16163]
>>
>>> http://rubyforge.org/tracker/index.php?func=detail&aid=16163&group_id 
>>> ...
>>
>>> it worked but a modification was made to ruby and the optimisation
>>> break the code now
>>
>> Before this question is relegated to the heap of "premature
>> optimization" ideas, I think the value of some level of programmer-
>> controller optimizations would be useful in the future. Optimizations
>> can break code so they are always "caveat programmer." Even in C,
>> where lots is known about the code, there are code-breaking
>> optimizations. Again, not a recommendation to do this; just a
>> recommendation not to dismiss it.
>>
>> Just my $.02
>
> Hm, couldn't you use method_added behind the scenes somehow? Perhaps
> use the opimized parse tree unless method_added is invoked? Or cache
> the parse tree?
>
> Or am I talking nonsense?

Probably, that would make sense for the 90th percentile of use. For  
some percentile, it'll be really bad.

obj.extend or re-opening the class inside a method could then be a  
killer, which brings us right back to optimisation

I guess the problem is, the people that need it, should know how to  
have the same effect on their code, those that don't just want it.  
sure it's probably not that well defined, but in seems close to the  
truth for many cases

>
>
> Regards,
>
> Dan
>