Ok, too much effort (time) to create "project" like test cases right
now (so we can test dependencies between files), I'll add that to my
ToDo list.
I did see that the "getAllImports()" method the compiler provides
apparently doesn't resolve dependencies (like I expected it to do,
since in the compiler and all) but only lists the "import" statements
that are in the file. So, my bad for wasting your time Alex, it looks
like your solution is the one we should have been looking for all
along. Just goes to show that the strength and weakness of unit
testing; weakness in the sense that if you don't write a test, it
won't fail ;-)
EdB
On Tue, Apr 9, 2013 at 3:16 PM, Erik de Bruin <e...@ixsoftware.nl> wrote:
> 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
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
