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.d...@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
>code:
>
> 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
it.
>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.
-Alex
