[mtasc] Optimizations

[Josh Baker]

I agree with you 100%.  I would vote for an optimization flag that both 
evaluates constants at compile-time and ~maybe~ raises an error when a 
common property or method is changed with the prototype keyword. 

Scott Hyndman wrote:

>Although that may be the case, I imagine this addition to the compiler
>would be a flag...and not at all necessary.
>
>I don't see how the underlying language has anything to do with these
>optimizations...but I guess it's all in how you see it. I personally
>would never use a string that way, so would have no problem applying
>this type of optimization.
>
>/Scott
>
>-----Original Message-----
>From: mtasc-bounces at lists.motion-twin.com
>[mailto:mtasc-bounces at lists.motion-twin.com] On Behalf Of Josh Baker
>Sent: Wednesday, June 22, 2005 2:40 PM
>To: MotionTwin ActionScript2 Compiler List
>Subject: Re: [mtasc] Optimizations
>
>Yes, that would be nice.  Basically, the compiler would assume a 
>variable which is created and assigned on a local stack to be considered
>
>a "constant" until it's re-assigned a different value.  That way common 
>methods/properties can be assumed at compile-time, such as String.charAt
>
>and String.length
>
>One major issue though,  this is a prototype language, and String.length
>
>may not be what the compiler expects by the time it reaches it.
>
>Example,
>
>class Tuto
>{
>    static function testStringMethod()
>    {
>        var str:String = "Scott";
>        TRACE("Testing [" + str + "] length : " + str.length);
>        if (str.length == 5)
>        {
>            TRACE("Equals 5");
>        }
>    }
>   
>    static function main()
>    {
>        testStringMethod();
>        String.prototype.addProperty("length", function(){return 20;}, 
>null);
>        testStringMethod();
>    }
>}
>
>Every single String.length call will return back 20 thereafter. 
>
>The only way to avoid this kind of jacking is a paradigm shift in the 
>Flash bytecode.  And this decision is not up to people outside of MM.
>
>
>
>Scott Hyndman wrote:
>
>  
>
>>That's the kind of thing I'm talking about.
>>
>>Or
>>
>>var str:String = "Scott";
>>
>>if (str.length == 5)
>> trace(str);
>>
>>To
>>
>>trace(str);
>>
>>-----Original Message-----
>>From: mtasc-bounces at lists.motion-twin.com
>>[mailto:mtasc-bounces at lists.motion-twin.com] On Behalf Of Michael
>>    
>>
>Bianco
>  
>
>>Sent: Wednesday, June 22, 2005 12:25 PM
>>To: Mark Winterhalder; MotionTwin ActionScript2 Compiler List
>>Subject: Re: [mtasc] Optimizations
>>
>>Does MTASC evaulate constant expressions such as if(4/2 == 2) to
>>if(true)?
>>That would be a nice optimization...
>>
>>On 6/22/05, Mark Winterhalder <mark13 at gmail.com> wrote:
>> 
>>
>>    
>>
>>>>What kind of optimizations are you thinking about ?
>>>>     
>>>>
>>>>        
>>>>
>>>how about an -inline <classname> parameter that inlines static methods
>>>of a given class to where they are called?
>>>that way one could have a tools class with often used operations (e.g.
>>>for vector math) and avoid the function call but still have them only
>>>at one place in the code.
>>>
>>>mark
>>>
>>>
>>>On 6/22/05, Nicolas Cannasse <ncannasse at motion-twin.com> wrote:
>>>   
>>>
>>>      
>>>
>>>>Is the MTASC compiler doing any optimizations on the code?
>>>>
>>>>
>>>>
>>>>Because if not, this might be an interesting direction to take it.
>>>>
>>>>
>>>>
>>>>/Scott
>>>>
>>>>What kind of optimizations are you thinking about ?
>>>>
>>>>Flash is inherently difficult to optimize because very dynamic, so
>>>>     
>>>>
>>>>        
>>>>
>>every
>> 
>>
>>    
>>
>>>>change in code structure might break something somewhere else.
>>>>
>>>>
>>>>
>>>>Nicolas
>>>>--
>>>>MTASC : no more coffee break while compiling
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>--
>>>http://snafoo.org/
>>>jabber: mark13 at jabber.org.uk
>>>--
>>>MTASC : no more coffee break while compiling
>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>
>--
>MTASC : no more coffee break while compiling
>
>--
>MTASC : no more coffee break while compiling
>
>
>  
>