Olaf, just a quick return to your initial issue. I did recreate something
similar with this:
[Bindable]
public class BindableWithConstructorInit
{
public static const STATIC_INIT:BindableWithConstructorInit = new
BindableWithConstructorInit( "STATIC_INIT" ,-1 );
public var ordinal:int;
public var value:String;
public function BindableWithConstructorInit ( value:String, ordinal:int )
{
this.value = value;
this.ordinal = ordinal;
}
public function equals( other:BindableWithConstructorInit ):Boolean
{
return ( this.ordinal == other.ordinal && this.value == other.value );
}
}
The const is actually being set up as a static bindable, which it should
not be. So that is one thing I need to fix.
And the other thing I saw was related to what Alex mentioned which is
related to static initialization, that in this example the STATIC_INIT
internal instance is being created before the 'value' getter/setter pair is
being defined.
I did not see the 'value' is undefined error, but it essentially created a
value field independent of the getter/setter and so the bindable support
was not viable on subsequent 'value' assignments.
I can take a look at these and any other related issues in a week's time if
no-one else can get to them first.
cheers
Greg
On Fri, Sep 30, 2016 at 5:38 PM, Greg Dove <greg.d...@gmail.com> wrote:
> 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
>>> >>>
>>> >>>
>>> >>
>>>
>>>
>>
>
