Hi Alex, if you have time, perhaps you can shed some light on this?

I have an mxml component using states, that implements an Interface, 
IFormSequence.

the generated CLASS_INFO looks like this:
FLEXJS_CLASS_INFO = { names: [{ name: 'ActionForm', qName: 
'components.forms.ActionForm', kind: 'class'  }], interfaces: 
[components.forms.IFormSequence] };

and the goog.require for the interface is there at the top
goog.require('components.forms.IFormSequence');

I notice that the 
goog.addDependency('../../../components/forms/IFormSequence.js', 
['components.forms.IFormSequence'], []);

appears after the 
goog.addDependency('../../../components/forms/ActionForm.js', 
['components.forms.ActionForm'], ['org.apache.flex.html.Group']);
in the index.html.
Perhaps the order here is not important and goog resolves everything somehow, 
but I did wonder if the dependency chain in for ActionForm.js above should also 
contain the interface (that's a question, not a suggestion - I don't know what 
is right here). At the moment there is an issue where there is an interface 
check on startup when states or styles or something like this are being 
initialized (it is actually a check for a different interface, but because the 
'interfaces' array is defined and has length in CLASS_INFO it looks there and 
tries to follow follow the inheritance chain on the undefined Interface 
reference, causing mayhem). Because the reference inside the CLASS_INFO 
evaluates to undefined, I know the dependencies are not loading in the right 
order. 

This was working last week so either it is something random/unlrelated 
elsewhere in the project that has changed the order, or the compiler has 
changed perhaps. Could your changes to goog.requires ordering have something to 
do with this, do you think?

I have not checked in the compiler to see if mxml "implements' is being treated 
the same as a regular actionscript 'implements' or if there are different code 
paths internally that might create differences for mxml based output vs regular 
AS, which was another thing I thought about here, because I think 'implements' 
is not often used in mxml. I'm happy to do that if you think that might warrant 
investigation, but figured I would check on whether you thought the other 
changes could be affecting this first.

Also, fyi, I was not using removeCirculars (although I don't *think* there are 
any circular references here and that part has not changed since it worked 
previously). fyi, when I tried remove circulars I got a compilation fail at 
org.apache.flex.compiler.internal.graph.GoogDepsWriter.getListOfFiles(GoogDepsWriter.java:103)






Reply via email to