Last night I found out that I could simply let the falcon SWFdump dump the swf
of the default compiler any I actually got results I could compare.
One thing that sprung my eyes immediately was that with the old compiler the
first two commands of every method I could find were identical and were
completely missing from the falcon code.
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 {
...
}
Could this cause problems?
Chris
-----Ursprüngliche Nachricht-----
Von: Alex Harui [mailto:[email protected]]
Gesendet: Samstag, 1. November 2014 19:41
An: [email protected]
Betreff: Re: AW: AW: [FALCON] Bindable interfaces?
I think you can set -compiler.compress=false and get Falcon to produce a SWF
that the old swfdump can dump.
On 11/1/14, 10:55 AM, "Christofer Dutz" <[email protected]> wrote:
>Well I sent the output of the default compiler through the default
>swfdump -abc with the falcon built swf of the same project using
>falcon-swfdump -abc ... unfortunateley I can't really compare the two
>directly. The falcon version is far more readable than the default one
>but is more than twice the size. From a brief look it does seem as if
>the generated code is as it should (even after commenting out the
>problematic code).
>
>Would really need to have a tool that automatically compiles a project
>with both and creates the swfdump of the results in a compareable way
>as my current manual way is rather anoying.
>
>Chris
>
>________________________________________
>Von: Alex Harui <[email protected]>
>Gesendet: Samstag, 1. November 2014 15:14
>An: [email protected]
>Betreff: Re: AW: [FALCON] Bindable interfaces?
>
>On 11/1/14, 6:25 AM, "Christofer Dutz" <[email protected]> wrote:
>
>>Ok ... digging through the handling of Bindable metadata it seems that
>>the code that was causing problems was redundant. The logic in
>>ASCompilationUnit that changed the parent class of classes extending
>>Object seems obsolete because even if commenting out the entire code
>>in ASCompilationUnit binding stil seems to work.
>>
>>So I guess we should remove this particular piece of code from
>>ASCompilationUnit. Probably this would also get rid of the problems I
>>was having.
>
>I would recommend find out where else the change to extend
>IEventDispatcher happens, and then maybe Gordon/Darrell would have a
>better opinion on how it should work.
>
>>
>>Well I tried to compare the generated outputs, but couldn't manage to
>>keep the generated output.
>>While looking for the reason for this, in
>>flex-falcon/compiler/src/org/apache/flex/compiler/config/Configuration
>>.ja
>>v
>>a
>>
>>I could see that the configuration of
>>compiler.keep-generated-actionscript is marked as not supported and
>>isn't implemented at all. I don't quite know how I should compare the output.
>
>It is true that Falcon does not keep-generated-actionscript. It
>generates ABC directly from the AST. That allows the opportunity to
>output ABC patterns that don’t have true or readable AS equivalents
>someday. I don’t think that is done now, but think about tail-call
>optimizations and things like that.
>
>Maybe I wasn’t clear, but I’m trying to say that MXMLC is the gold
>standard. You want to compare MXMLC’s output with and without
>[Bindable] and then teach Falcon to do the same.
>Keep-generated-actionscript should work there for a lot of it, but I
>would also use SWFDump -abc to see things that aren’t apparent in the
>generated AS.
>
>-Alex
>
