From: Eric Hodel <drbrain@...7.net>
Date: 2008-03-29T09:06:55+09:00
Subject: Re: Why Ruby do not optimize code at all?

On Mar 28, 2008, at 08:39 AM, James Tucker wrote:
>>> Some optimization maybe affects debugging process.
>>> Nevertheless, it seems "Constant folding" is not harmful but  
>>> helpful.
>>> I tried some pre-evaluation of constant or literal nodes in parsing
>>> time.
>
> As said by others, open classes means parse time != run time, at all.
>
>>> Consider this code
>>>
>>> i = 320 * 200 * 32
>
> The only time I could see this being sensible to do is if it's  
> actually closer to:
>
> A = 320.freeze
> B = 200.freeze
> C = 32.freeze
>
> i = A * B * C

#freeze is not a solution to the constant folding optimizations.  It  
only makes the object immutable, not it's class, and not its  
instance_variables, so methods may be redefined on you anyhow, and the  
contents of ivars may also change (String#replace, etc.)

> However, the realistic implications are that freeze plus the  
> discussed optimization causes a pre-processor fixed definition of  
> the methods A.*() and B.*().
>
> In MRI, one can unfreeze too, so this still isn't "safe", and the  
> source code does not resemble what is run.

You can taint/untaint, but you cannot unfreeze.