Technically, no.  We know how to fix this, but the solution is not that simple.

The problem is the script compiler does not know the lexical context or a 
method (the instance vars), so it can't be sure that there is not an instance 
var named 'String' or 'lz' that is shadowing the global.

The script compiler _does_ know the instance vars for the classes it is 
compiling, but when it is compiling user-code, it does not know the instance 
vars of any superclass that is in the LFC.  The correct solution is for the LFC 
compile to write out the class-description data structures of the LFC classes 
alongside the LFC and for the compiler to read those back in when compiling 
user code.

You may still say SMOP, which I don't dispute.  Time is still involved.

And again, this is not an issue for the swf10 runtime.  The flex compiler 
already is smart enough to do this.

On 2010-12-04, at 13:38, Max Carlson wrote:

> In most of cases, the compiler is failing to recognize globals that are safe, 
> e.g. String, Math and lz.  It seems like it should be fairly easy to add 
> known globals to the list, SMOP right?
> 
> 
> On 12/3/10 12:46 PM, P T Withington wrote:
>> Yes.
>> 
>> This is our (lazy) way of implementing classes in ES3, which we should fix 
>> if it means Max can work on more important things than doing the compiler's 
>> job by hand.  Too bad we don't have a compiler guru on the OL team...
>> 
>> Basically, the compiler is doing a very simple analysis of each method body, 
>> and if there are _any_ free references in the body, it wraps `with(this)` 
>> around the body to simulate the lexical lookup of instance var's.
>> 
>> With a teeny bit more mechanism, the compiler could instead compare those 
>> free references to the the instance vars in the class model and rewrite them 
>> to `this.`, dispensing with the need for `with(this)`.  This should result 
>> in a significant speed-up in our DHTML code, because `with` slows all free 
>> lookups (and is not even available in ES5 strict).
>> 
>> I haven't prioritized this in the past, because, long-term, we should adopt 
>> a more modern implementation of classes in DHTML, based on traits 
>> (http://code.google.com/p/es-lab/wiki/Traits), when we can reliably expect 
>> all browsers to be supporting ES5.
>> 
>> And, none of this is a problem on as3, because it _already_ implements 
>> lexical binding of instance vars in classes correctly.
>> 
>> On 2010-12-03, at 15:21, Henry Minsky wrote:
>> 
>>> What's going on with "with(this)" ? Is the compiler putting in when it sees
>>> what it thinks is a free global reference?
>>> 
>>> On Fri, Dec 3, 2010 at 8:17 AM, P T Withington<[email protected]>wrote:
>>> 
>>>> Approved.  It's damned annoying the compiler is not figuring that out for
>>>> itself.
>>>> 
>>>> We should upgrade corner radius to handle 8 values and move the
>>>> borderradius parser into lz/mixins (or maybe just add it to boxmodel)?
>>>> 
>>>> 
>> 


Reply via email to