Pretty sure our emails crossed paths.
You can probably keep all of your formatQualfiedName calls. I cast
getEmitter to JSFlexJSEmitter and added the isDoc parameter for calls
during the header and reflection data output since that output shouldn't
affect the set of used names.
-Alex
On 9/29/16, 8:53 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>Alex, I think perhaps the primary cause of this is in the output of the
>qualified names in the reflection data.
>In many cases they were not output as fully qualified previously, because
>they were not completely resolved, my fixing this may have added to the
>dependency list I think.
>
>It was also wrapping this using formatQualifiedName historically, but it
>was not often outputting the qualified name
>example before the changes:
>data.type = getEmitter().formatQualifiedName(fnNode.getReturnType());
>
>I changed this to :
>String qualifiedTypeName = fnNode.getReturnType();
>if (!(qualifiedTypeName.equals("") || qualifiedTypeName.equals("void"))) {
>qualifiedTypeName = fnNode.getReturnTypeNode().res
>olveType(getProject()).getQualifiedName();
>}
>data.type = getEmitter().formatQualifiedName(qualifiedTypeName);
>
>So I am not sure if this is wrong or not (that it is using the
>formatQualifiedName call), but if it is wrong it is because the
>'qualifiedName' before this change seemed to be not working right (i.e. it
>was often not the fully qualified name).
>I *think* this might be the reason, or at least a solid part of it.
>Certainly removing a number of the formatQualifiedName calls from
>PackageFooterEmitter improves things.
>
>I suspect at this point, the change is a side effect of these fixes. But
>if
>these are removed then reflection may not work properly.
>
>
>Example
>
> public class CoreTester
> {
> public var strandTesterTest:StrandTesterTest;
>public var binaryDataTesterTest:BinaryDataTesterTest;
> }
>
>In the above case, the addition of the fully qualified types for the
>variables are the only dependency link to the Test classes in the project.
>If these are not goog.required then you cannot acquire the actual type of
>the Test classes at runtime and run their tests.
>
>
>
>
>
>On Fri, Sep 30, 2016 at 3:02 PM, Greg Dove <greg.d...@gmail.com> wrote:
>
>> I found one cause of the circular dependencies, that usedNames change
>>was
>> only in the mxml emitter, sorry that was a bad suggestion (I was not
>> looking at the code at the time).
>>
>> I am currently looking at options, I will try it with the change I found
>> (removing a formatQualifiedName call in PackageFooterEmitter)
>>
>> I guess I am not sure what makes sense here in terms of finding the
>>right
>> balance.
>>
>>
>>
>> On Fri, Sep 30, 2016 at 11:29 AM, Alex Harui <aha...@adobe.com> wrote:
>>
>>>
>>>
>>> On 9/29/16, 3:18 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>>>
>>> >That's almost like a dependency analysis pass within the class itself
>>> >isn't
>>> >it? To rearrange the ordering, I mean.
>>>
>>> I think it means determining the difference between scalar and
>>>non-scalar
>>> initializer values. We already do something like this for instance
>>> properties. Static properties can be initialized to scalar values in
>>>any
>>> order, but any initial values as a result of function calls and other
>>> lookups should be run in a class initializer in which case order in the
>>> source file might always be right, or at least more right than what we
>>> have now. When to kick off the class initializer is an interesting
>>> question. Flash runs the class initializer from the verifier. There
>>>is
>>> essentially no such thing for JS. Running all class initializers at
>>> startup is an undesirable solution.
>>>
>>> >
>>> >If I can see a quick solution to the above I might add it today, but
>>> >perhaps it is better to wait and try to figure out the bigger problem.
>>>
>>> If you still have some time, I'm about to start digging into the
>>> re-introduction of circular dependencies in the examples like
>>> DataBindingExample. I suspect the new code you added to the
>>>postProcess
>>> but have no proof yet. If you look at Strand.js, it has a goog.require
>>> for IBead, but there is no reference to IBead in Strand.js. The String
>>> 'Ibead' is in the reflection data, but not a reference to the class.
>>>I'm
>>> pretty sure Strand shouldn't require IBead. I'm wondering what cases
>>>you
>>> ran into that caused the new code in postProcess.
>>>
>>> Thanks,
>>> -Alex
>>>
>>>
>>
