flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: AW: AW: AW: [FALCON] Bindable interfaces?
Date Mon, 03 Nov 2014 05:29:22 GMT
I’m going to try to consolidate your last set of emails into this post.

On 11/2/14, 12:45 PM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:

>Even if I could not 100% confirm the code was doing the same as compared
>to the default compiler. I could confirm that removing the code I was
>thinking of being redundant didn't have any effect on the generated
>output. The classes abc code were identical. So I guess it's safe to
>assume, that removing the code doen't break anything.

I’m concerned that removing that code is going to break some scenario
involving binding to a bindable class.  Maybe Darrell or Gordon can
provide more information, but the code you are removing is in
handleSyntaxTreeRequest, and the code you are relying on is part of
handleABCBytesRequest.  I think handleSyntaxTreeRequest is called when
some other class is trying to reference members of the class being
compiled, and handleABCBytesRequest is called to output the ABC to the
SWF/SWC.  Did your scenario have some other class call addEventListener on
the class being compiled, or bind to the class being compiled?

>Ok ... so I found out what the first two commands are:
>get "this" and make it the scope ... makes sense to have this in every
>non-static function, but why is this missing in falcon?
>Every function call in the default compiler results in these two lines of
>      0       getlocal0
>      1       pushscope
>these are missing in Falcon compiled code.

I don’t know for sure.  It could be that, with strict mode, you don’t need
scope in certain scenarios.  Again, maybe Darrell or Gordon can answer.

>Another change I found was that in Falcon compiled code the Metadata is
>kept at class level while the default compiler moves the metadata to the
>property. Ist this of any significance? I could immagine that if I have a
>class extending a falcon compiled class then all properties in this
>extension would be bindable too, if extending a default compiler compiled
>class I would only expect the properties of the base class bindable. But
>that's just wild guessing ... reading ABC code is something I'm not
>really familiar with.

That could be a bug.  Again we’ll need to find a test case that exploits

>But ignoring the first two statements (even a one-line return null
>function had these). The results were semantically allmost identical.
>Only the setter of a Bindable variable were slightly differntly
>implemented and the private variable didn't have the number prefix ...
>don't know if this could be a problem:
>private var tst:String;
>public function set tst(val:String):void { ...
>pubic function get tst():String {

In theory, the private var is actually in a namespace.


View raw message