If this does break reflection, then I can certainly accept that reflection
is probably not mainstream enough to warrant keeping things as they were,
but it would be nice to be able to keep more aggressive 'requires' settings
here for reflection as an option, so long as remove circulars can handle
whatever comes out. Have I understood the issue correctly?
On Fri, Sep 30, 2016 at 5:04 PM, Greg Dove <greg.d...@gmail.com> wrote:
> Please check with the GenericTests manual test after that change.
>
> I thought I saw that the return types of the methods or variable types
> were not affecting usedNames directly during output and it was only be
> picked up in the reflection data.
>
> If GenericTests works fine after your changes then I am very wrong!
>
>
>
>
> On Fri, Sep 30, 2016 at 4:59 PM, Alex Harui <aha...@adobe.com> wrote:
>
>> 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
>> >>>
>> >>>
>> >>
>>
>>
>
