flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] Issue with bindable class
Date Fri, 30 Sep 2016 03:59:05 GMT
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.


On 9/29/16, 8:53 PM, "Greg Dove" <greg.dove@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
>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
>these are removed then reflection may not work properly.
> 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.dove@gmail.com> wrote:
>> I found one cause of the circular dependencies, that usedNames change
>> 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
>> balance.
>> On Fri, Sep 30, 2016 at 11:29 AM, Alex Harui <aharui@adobe.com> wrote:
>>> On 9/29/16, 3:18 PM, "Greg Dove" <greg.dove@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
>>> initializer values.  We already do something like this for instance
>>> properties.  Static properties can be initialized to scalar values in
>>> 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
>>> 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
>>> 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.
>>> pretty sure Strand shouldn't require IBead.  I'm wondering what cases
>>> ran into that caused the new code in postProcess.
>>> Thanks,
>>> -Alex

View raw message