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
