I'm writing test cases for all of the issues you mentioned to see how
the current code behaves (and so we can test the new code if it's
needed).

EdB



On Tue, Apr 9, 2013 at 2:05 PM, Alex Harui <aha...@adobe.com> wrote:
> I still think using imports is insufficient.
>
> Here's a simple example:
>
> ClassA.as
> package comps
> {
>     public class A
>     {
>         public function A()
>         {
>             var foo = new B();
>         }
>     }
>
> }
>
> ClassB.as
> package comps
> {
>     public class B
>     {
>         public function B()
>         {
>         }
>     }
> }
>
> TestApp.as
> package
> {
>     import comps.A;
>
>     public class TestApp
>     {
>         public function TestApp()
>         {
>             var bar = new A();
>         }
>     }
> }
>
> In this example, when TestApp is compiled, it will compile A and B, but
> there are no imports for B so it won't add a goog.requires("comps.B");
>
> And then there is handling wild-card syntax (import comps.*) and unnecessary
> goog.requires if I forget to remove an import statement.  For example, what
> do you want the list of requires to look like for this sloppy code:
>
> TestApp2.as
> package
> {
>     import comps.HugeClassA;
>     import comps.HugeClassB;
>
>     public class TestApp2
>     {
>         public function TestApp2()
>         {
>         }
>     }
> }
>
> IMO, there shouldn't be any requires.  Someone simply forgot to clean up
> their imports.
>
> It turns out that Falcon builds out a set of dependencies between
> compilation units that don't rely on import statements.  It relies on the
> attempt to resolve indentifiers when compiling code.  This is much more
> reliable and robust.  That's how FalconJS works and it was pretty easy to
> copy it to FalconJX.
>
> In summary, relying on imports for dependencies is not the right approach.
> For MXML, relying on tags you found helps, but doesn't take care of
> dependencies in the script block or event handlers.
>
>
> On 4/9/13 10:44 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>
>> The FalconJX::MXMLFlexJSEmitter implementation keeps track of which
>> types ("instances") are actually used in the MXML and writes the
>> "goog.requires" from that list.
>>
>> The FalconJX::JSGoogEmitter (the parent class of JSFlexJSEmitter) uses
>> the "getAllImports" method on the ScopedNode representing the AS
>> class.
>>
>> These two seem to be sufficiently generic to "work".
>>
>> I think you are referring to the handling of the imports in a
>> fx:script tag in MXML, correct? I'm sure we can use one of the methods
>> above to handle those as well.
>>
>> Or do you have a rewrite that handles all three "types" of imports?
>>
>> EdB
>>
>>
>>
>> On Tue, Apr 9, 2013 at 12:25 PM, Alex Harui <aha...@adobe.com> wrote:
>>>
>>>
>>>
>>> On 4/9/13 9:52 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>>>
>>>> Ah, hard for me to review ;-)
>>>>
>>>> Do you plan to commit it, or do you want me to look at the current
>>>> implementation and try to fix that?
>>>>
>>> If it builds the test app and my customer's app then I will check it in.  It
>>> sounds like you agree that using imports is insufficient.
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>
>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Reply via email to