> I don’t have any objection to making a few changes like this to the SDK to > get past this issue. I’m definitely curious to know how much resulting JS > there will be from compiling the SDK. >
I’m still working on getting ADVANCED OPTIMISATIONS working with the SDK + Flash Player + application JS combo. However, with SIMPLE OPTIMISATIONS, which includes all code and the kitchen sink - it’s basically whitespace removal, it doesn’t recompile the JS - the output file is a whopping 2 Mb! Cool, huh ;-) I expect some serious reduction in file size when the GCC is able to actually parse an entire application and optimise the code properly … We’ll see. > That said, what is the plan for when FalconJX compiles some users code > that has tons of these patterns? Will we just output an error? Might be > nice to have that error/warning in the AS compile. > FalconJX should properly parse this construct. That will be challenging though, as we’d need to look forward in the AST and then handle these multiple catch blocks and turn them into a proper set of ‘if … then’ statement in a single catch block. Also, how “heavy” is this problem? Are the catch nodes children of the > try node? If so, could we just rewrite the AST there? > Actually, hoping to get a blessing for rewriting the SDK, I didn’t look at the AST at all :-) EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
