flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Dove <greg.d...@gmail.com>
Subject Re: [FlexJS] Issue with bindable class
Date Fri, 30 Sep 2016 03:53:43 GMT
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 if
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 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 <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 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message