And then I discovered that, even with my own dependency generator, when you
pass this set to the closure compiler for optimization it barfs on the
circularity and there won't be any working around that.
I'm testing out a change to the dependency list logic to try to detect
circularities up front. The logic is basically: if someone has already
require'd that class then you shouldn't need to require it.
But I'm still wondering if goog.require is supposed to be for all
requirements or just for prototype requirements and if we're supposed to
resolve other dependencies some other way. For example:
public class A extends Base
{
public function A()
{
var foo = new B();
bar = new C(this);
}
private var bar:C;
}
public class C
{
public function C(owner:Object)
{
this.owner = owner;
}
private var owner:A;
}
The only hard dependency is on Base.
It is in the adding of requires for B and C that you get circularities. But
technically, it doesn't matter when B and C get loaded as long as they get
loaded before you instantiate A.
For a more "real" example, look at FlexJSTest_again.mxml and
MyController.as. FlexJSTest_again instantiates MyController, and
MyController wants a back reference to FlexJSTest_again. MyController
doesn't import FlexJSTest_again because FlexJSTest_again is in the default
namespace, but the new dependency code will add a requires to MyController
for FlexJSTest_again and a circularity is formed. It seems like only
dependencies like the base class and instance and static initializers should
be in the requires list for a class and maybe all other dependencies should
be in another list of requires for the main app.
On 4/9/13 2:22 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
> 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
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
