You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by OK <po...@olafkrueger.net> on 2016/09/29 21:06:22 UTC
[FlexJS] Issue with bindable class
Hi,
while porting the PureMVC employee admin demo to FlexJS I stumbled over
another issue which I don't understand:
The demo makes use of a 'typesafe enum pattern' which class that implements
it is declared as 'Bindable' [1].
It compiles without any errors or warnings and the swf side works fine.
But for the JS side it throws a silent 'TypeError: value is undefined' and
so it doesn't work.
If I remove the 'Bindable' tag from the class it works fine.
To be clear:
I don't need to make the class Bindable but I'd like to understand this
behaviour.
There were no hints by the compiler and the browsers TypeError doesn't point
me to the right direction so I was lost for a while.
Is this issue maybe based on the 'circular dependency' thing?
Thanks,
Olaf
[1]
https://github.com/PureMVC/puremvc-as3-demo-flex-employeeadmin/blob/master/src/org/puremvc/as3/demos/flex/employeeadmin/model/enum/DeptEnum.as
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Issue-with-bindable-class-tp55468.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
Quick check: Is this using 0.7 release, or latest development builds?
On Fri, Sep 30, 2016 at 10:06 AM, OK <po...@olafkrueger.net> wrote:
> Hi,
> while porting the PureMVC employee admin demo to FlexJS I stumbled over
> another issue which I don't understand:
> The demo makes use of a 'typesafe enum pattern' which class that implements
> it is declared as 'Bindable' [1].
> It compiles without any errors or warnings and the swf side works fine.
> But for the JS side it throws a silent 'TypeError: value is undefined' and
> so it doesn't work.
> If I remove the 'Bindable' tag from the class it works fine.
>
> To be clear:
> I don't need to make the class Bindable but I'd like to understand this
> behaviour.
> There were no hints by the compiler and the browsers TypeError doesn't
> point
> me to the right direction so I was lost for a while.
> Is this issue maybe based on the 'circular dependency' thing?
>
> Thanks,
> Olaf
>
>
> [1]
> https://github.com/PureMVC/puremvc-as3-demo-flex-
> employeeadmin/blob/master/src/org/puremvc/as3/demos/flex/
> employeeadmin/model/enum/DeptEnum.as
>
>
>
>
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-Issue-with-
> bindable-class-tp55468.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: [FlexJS] Issue with bindable class
Posted by Alex Harui <ah...@adobe.com>.
On 9/29/16, 3:59 PM, "Greg Dove" <gr...@gmail.com> wrote:
>I did wonder if this stuff could be refactored so that different parts of
>the output were buffered and then output in sequence at the end instead of
>having to use the postProcess approach, although I have no idea what
>implications that might have for memory or speed. Does that make any
>sense?
A refactoring might help things, but who's going to do it and when? Right
now my thinking is that what we have is good enough to get to 1.0 and
maybe if we get momentum someone who knows this stuff better will show up
and help us. We already do "buffer" with stringifyNode, But sometimes I
think even stringifyNode calls stringifyNode. At some point, you have to
put some code in the output file.
-Alex
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
I did wonder if this stuff could be refactored so that different parts of
the output were buffered and then output in sequence at the end instead of
having to use the postProcess approach, although I have no idea what
implications that might have for memory or speed. Does that make any sense?
On Fri, Sep 30, 2016 at 11:38 AM, Greg Dove <gr...@gmail.com> wrote:
> I was seeing examples of situations where new 'usedNames' were being added
> during the output of the js but were not captured in the goog.requires
> output.
>
> This caused 'x is undefined' sometimes so that is what I was trying to
> address.
> I don't have time right now, but I can come back to this later in my day
> (midday Friday right now for me).
>
> Perhaps if you comment out the 'namesToAdd' stuff in postProcess it might
> behave like it was reverted and you can check if that removes the Strand
> problem.
>
>
>
>
> On Fri, Sep 30, 2016 at 11:29 AM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 9/29/16, 3:18 PM, "Greg Dove" <gr...@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
>>
>>
>
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
I was seeing examples of situations where new 'usedNames' were being added
during the output of the js but were not captured in the goog.requires
output.
This caused 'x is undefined' sometimes so that is what I was trying to
address.
I don't have time right now, but I can come back to this later in my day
(midday Friday right now for me).
Perhaps if you comment out the 'namesToAdd' stuff in postProcess it might
behave like it was reverted and you can check if that removes the Strand
problem.
On Fri, Sep 30, 2016 at 11:29 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 9/29/16, 3:18 PM, "Greg Dove" <gr...@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
>
>
Re: [FlexJS] Issue with bindable class
Posted by Alex Harui <ah...@adobe.com>.
On 9/29/16, 7:02 PM, "Greg Dove" <gr...@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.
I am also looking into a solution. IMO, many of the calls to
formatQualifiedName should have the "isDoc" parameter set to true because
you don't want to add the name to the used names.
-Alex
Re: [FlexJS] Issue with bindable class
Posted by OK <po...@olafkrueger.net>.
Hi Greg and Alex,
thanks for helping out!
>I did not see the 'value' is undefined error...
Probably it's not needed but to avoid confusion I've created a small test
case [1].
I've also added the JS output of the related Enum class and some screenshots
of the browser output to the repo. Maybe this is helpful.
Olaf
[1] https://github.com/ok-at-github/flexjs-bindable-with-constructor-init
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Issue-with-bindable-class-tp55468p55490.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Issue with bindable class
Posted by Alex Harui <ah...@adobe.com>.
I modified the GenericTest and pushed changes. See the comments in
CoreTester about the pattern for force-linking.
On 9/30/16, 12:24 AM, "Greg Dove" <gr...@gmail.com> wrote:
>I did have another somewhat related thought.... I can't check it now, but
>if GCC removes 'dead code' (methods or properties not explicitly
>referenced
>anywhere in the project) do the @export and @expose markers protect
>against
>that?
AFAIK, those directives don't prevent dead-code removal.
I believe we can further seed GCC with renaming rules/information which
might give us better control someday if we need to make reflection work
after we sweep away most directives to save on string table size.
Have a good vacation,
-Alex
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
Yeah I had considered the same thing - simply Adding concrete references in
the TestClasses.as. It's a simple enough 'fix, just slightly less 'elegant'
(which is fine).
I didn't actually add those formatting calls that ultimately added to
usedNames from the footer. I believe I just fixed the names they were
passing which then ended up not being filtered out (can't remember the
details), so I had assumed that at some point someone wanted them to work
as they were.
I agree though, reflection alone is not a sufficient justification for this.
I don't know offhand if there are other scenarios outside of the way the
test classes are set up that would require this level of dependency without
at least concrete references somewhere else in the project.
I did have another somewhat related thought.... I can't check it now, but
if GCC removes 'dead code' (methods or properties not explicitly referenced
anywhere in the project) do the @export and @expose markers protect against
that?
I haven't seen this happen so perhaps they are safe. Otherwise that could
break reflection too, when the reflection data still represents the full
set of things that should be there and attempts are made for access the
fields dynamically..
Anyhow, have a great week, ttyl
cheers
Greg
On Fri, Sep 30, 2016 at 7:43 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 9/29/16, 9:04 PM, "Greg Dove" <gr...@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!
>
> I tried GenericTests. It fails to find some classes because, in order to
> reduce the likelihood of circularities (and reduce output size), the
> FalconJX code doesn't include classes that are only referenced via a type
> declaration instead of a concrete reference to the class.
>
> I suppose we could offer an option to change the logic, but my thinking is
> that, since JS isn't strongly typed in the runtime, it doesn't make sense
> to drag in code just for a parameter or variable type. Nothing will check
> that code except for reflection-oriented things like this test and this
> test could just make a concrete reference.
>
> I'm done for tonight. If you are already out on vacation and I don't hear
> from you I'll probably just make concrete references in GenericTests and
> commit everything.
>
> Thoughts?
> -Alex
>
>
Re: [FlexJS] Issue with bindable class
Posted by Alex Harui <ah...@adobe.com>.
On 9/29/16, 9:04 PM, "Greg Dove" <gr...@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!
I tried GenericTests. It fails to find some classes because, in order to
reduce the likelihood of circularities (and reduce output size), the
FalconJX code doesn't include classes that are only referenced via a type
declaration instead of a concrete reference to the class.
I suppose we could offer an option to change the logic, but my thinking is
that, since JS isn't strongly typed in the runtime, it doesn't make sense
to drag in code just for a parameter or variable type. Nothing will check
that code except for reflection-oriented things like this test and this
test could just make a concrete reference.
I'm done for tonight. If you are already out on vacation and I don't hear
from you I'll probably just make concrete references in GenericTests and
commit everything.
Thoughts?
-Alex
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
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 <gr...@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 <gr...@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 <ah...@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" <gr...@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 <gr...@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 <ah...@adobe.com>
>>> wrote:
>>> >>
>>> >>>
>>> >>>
>>> >>> On 9/29/16, 3:18 PM, "Greg Dove" <gr...@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
>>> >>>
>>> >>>
>>> >>
>>>
>>>
>>
>
Re: [FlexJS] Issue with bindable class
Posted by Alex Harui <ah...@adobe.com>.
On 9/29/16, 9:38 PM, "Greg Dove" <gr...@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?
IMO, we don't want the examples to require the -remove-circulars option
unless it uses a third-party library that has circularities. IMO, folks
often try to compile our examples from the command line and don't add the
-remove-circulars option so they get an error and that isn't a good
first-time-user experience.
I can't think of any reason we can't have good reflection data though.
IMO, the reflection subsystem should use reflection in order to prevent
circularities. The data in the reflection info uses strings of qualified
names instead of actual references to classes in order to break the
circularities. The reflection code can convert those strings to actual
references on-demand.
-Alex
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
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 <gr...@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 <ah...@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" <gr...@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 <gr...@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 <ah...@adobe.com> wrote:
>> >>
>> >>>
>> >>>
>> >>> On 9/29/16, 3:18 PM, "Greg Dove" <gr...@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
>> >>>
>> >>>
>> >>
>>
>>
>
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@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" <gr...@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 <gr...@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 <ah...@adobe.com> wrote:
> >>
> >>>
> >>>
> >>> On 9/29/16, 3:18 PM, "Greg Dove" <gr...@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
> >>>
> >>>
> >>
>
>
Re: [FlexJS] Issue with bindable class
Posted by Alex Harui <ah...@adobe.com>.
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" <gr...@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 <gr...@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 <ah...@adobe.com> wrote:
>>
>>>
>>>
>>> On 9/29/16, 3:18 PM, "Greg Dove" <gr...@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
>>>
>>>
>>
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
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 <gr...@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 <ah...@adobe.com> wrote:
>
>>
>>
>> On 9/29/16, 3:18 PM, "Greg Dove" <gr...@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
>>
>>
>
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@adobe.com> wrote:
>
>
> On 9/29/16, 3:18 PM, "Greg Dove" <gr...@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
>
>
Re: [FlexJS] Issue with bindable class
Posted by Alex Harui <ah...@adobe.com>.
On 9/29/16, 3:18 PM, "Greg Dove" <gr...@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
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
That's almost like a dependency analysis pass within the class itself isn't
it? To rearrange the ordering, I mean.
Sounds like another fun iteration through test maintenance!
I might not get to that at this point, as I will be afk for a week or so on
a vacation with my kids.
I don't want to start anything I can't finish quickly before I leave, but
I'm happy to tackle stuff like that after I get back.
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.
On Fri, Sep 30, 2016 at 11:12 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 9/29/16, 3:06 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> >it might be to do with the order of output I think.
> >Perhaps it is calling the bindable setter within the constructor but it is
> >not yet defined. Maybe this could also be covered by setting the private
> >backing var if inside the constructor for a bindable field.
> >
> >I can try to repro this later today and see if that is what is happening,
> >if so I will try to figure out a solution.
>
> I don't remember if there is a JIRA for this, but there are some issues
> with the way static initializers get run so if you do run into something
> like that, it might be time to solve the general static initializer
> problem.
>
> -Alex
>
>
Re: [FlexJS] Issue with bindable class
Posted by Alex Harui <ah...@adobe.com>.
On 9/29/16, 3:06 PM, "Greg Dove" <gr...@gmail.com> wrote:
>it might be to do with the order of output I think.
>Perhaps it is calling the bindable setter within the constructor but it is
>not yet defined. Maybe this could also be covered by setting the private
>backing var if inside the constructor for a bindable field.
>
>I can try to repro this later today and see if that is what is happening,
>if so I will try to figure out a solution.
I don't remember if there is a JIRA for this, but there are some issues
with the way static initializers get run so if you do run into something
like that, it might be time to solve the general static initializer
problem.
-Alex
Re: [FlexJS] Issue with bindable class
Posted by Greg Dove <gr...@gmail.com>.
it might be to do with the order of output I think.
Perhaps it is calling the bindable setter within the constructor but it is
not yet defined. Maybe this could also be covered by setting the private
backing var if inside the constructor for a bindable field.
I can try to repro this later today and see if that is what is happening,
if so I will try to figure out a solution.
On Fri, Sep 30, 2016 at 10:18 AM, OK <po...@olafkrueger.net> wrote:
> I'm using the nightly build.
>
> >If you can show us the generated code and the error it might give us a
> clue.
>
> For today I'm done, will provide it soon!
>
> Thanks,
> Olaf
>
>
>
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FlexJS-Issue-with-
> bindable-class-tp55468p55471.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Re: [FlexJS] Issue with bindable class
Posted by OK <po...@olafkrueger.net>.
I'm using the nightly build.
>If you can show us the generated code and the error it might give us a
clue.
For today I'm done, will provide it soon!
Thanks,
Olaf
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Issue-with-bindable-class-tp55468p55471.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Issue with bindable class
Posted by Alex Harui <ah...@adobe.com>.
Are you using the nightly build? There's been a fair amount of changes to
what [Bindable] does since 0.7.0. Could still be bugs in there though.
[Bindable] can have a great effect on the generated code. It changes the
super class from Object to EventDispatcher and then converts every var to
a get/set pair. If you remove [Bindable] then changes to the vars on this
class will not be detected after initialization.
If you can show us the generated code and the error it might give us a
clue.
-Alex
On 9/29/16, 2:06 PM, "OK" <po...@olafkrueger.net> wrote:
>Hi,
>while porting the PureMVC employee admin demo to FlexJS I stumbled over
>another issue which I don't understand:
>The demo makes use of a 'typesafe enum pattern' which class that
>implements
>it is declared as 'Bindable' [1].
>It compiles without any errors or warnings and the swf side works fine.
>But for the JS side it throws a silent 'TypeError: value is undefined' and
>so it doesn't work.
>If I remove the 'Bindable' tag from the class it works fine.
>
>To be clear:
>I don't need to make the class Bindable but I'd like to understand this
>behaviour.
>There were no hints by the compiler and the browsers TypeError doesn't
>point
>me to the right direction so I was lost for a while.
>Is this issue maybe based on the 'circular dependency' thing?
>
>Thanks,
>Olaf
>
>
>[1]
>https://github.com/PureMVC/puremvc-as3-demo-flex-employeeadmin/blob/master
>/src/org/puremvc/as3/demos/flex/employeeadmin/model/enum/DeptEnum.as
>
>
>
>
>--
>View this message in context:
>http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Issue-with-bin
>dable-class-tp55468.html
>Sent from the Apache Flex Development mailing list archive at Nabble.com.