This seems like a reasonable enough workaround. I really wish GCC weren't always giving us so many issues. I know many of them are "by design", but it gets frustrating very quickly.
- Josh On Wed, Oct 5, 2016 at 9:26 AM, Alex Harui <aha...@adobe.com> wrote: > So I replaced the @expose usage with @export on Accessors and looked into > why things don't work when you do that. It probably is a bug in GCC, but > I saw an article where GCC developers say that all static definitions are > considered separate "globals" and not properties of something. It is an > interesting philosophy: that statics are just groupings of global > variables. Thus I think it is not obvious to GCC that a property defined > in the Object.defineProperty structure is the same one being referenced by > other code. I don't see any annotations we can use to connect the > defineProperty info to the class definition. > > In related GCC issues, the GCC authors recommend using obj['someProp'] > instead of @export. There as also another article about how property > names in Object.defineProperty aren't going to get renamed anyway since > they are referenced as strings or as keys in the Object.defineProperties > structure. So, I've tested out a change to the compiler where any access > to a static accessor (and only static accessors since instance accessors > don't have this problem) will be done via obj['someProp'] instead of > obj.someProp. Yes, that makes the code a bit uglier, but it seems to solve > this problem. > > That's actually a nice advantage of having a compiler. We can write our > code using obj.someProp and the compiler can output something else more > suitable for GCC. > > Anyway, I wanted to see if anyone objects to this change before I push it. > I'm about to start to propagate this change through the unit tests before > committing. > > Thoughts? > -Alex > > On 10/3/16, 10:58 PM, "Alex Harui" <aha...@adobe.com> wrote: > > >I pushed changes to generate exportSymbol/exportProperty for certain > >metadata names. It fixed the ReflectionTests in GenericTests. > > > >I also modified ObservedBugs so that it wouldn't get optimized away. IMO, > >folks will just have to realize that certain patterns can be optimized > >away. It might be possible to use the @throws jsdoc annotation as well, > >but I'll leave that for someone else to try. > > > >Next up, undo the @expose for accessors and see if there is an alternative > >solution. > > > >-Alex > > > >On 10/3/16, 11:07 AM, "Alex Harui" <aha...@adobe.com> wrote: > > > >> > >> > >>On 10/3/16, 10:51 AM, "Greg Dove" <greg.d...@gmail.com> wrote: > >> > >>>That sounds great Alex. Good sleuthing. As keep as3 metadata provides > >>>for > >>>specific metadata don't you think this could be default for the class > >>>members with specific kept metadata? Given that the only reason for > >>>keeping > >>>it would be for reflection, I mean? I will be happy with the option here > >>>no > >>>matter how it is implemented though. Thanks! > >> > >>Not sure I understood what you meant. > >> > >>The default set of keep-as3-metadata includes things like [Bindable] and > >>I > >>think we want to allow unused [Bindable] properties to be removed by > >>default. I think the set of keep-code-with-metadata we ship could be > >>empty or include some FlexUnit metadata. > >> > >>In trying to implement this, there is an interesting issue. If we > >>process > >>keep-code-with-metadata in COMPJSC when cross-compiling a library, then > >>you might end up with exportProperty calls in the .JS files and later > >>when > >>you use that library in building an app, we have to decide whether the > >>keep-code-with-metadata assigned to the MXMLJSC run should also apply to > >>the JS files it is linking to. If "yes", then we need to keep around > >>data > >>about why an exportProperty is in a JS file from COMPJSC so we can prune > >>stuff out. Or we have MXMLJSC, but not COMPJSC, scan all .JS files, even > >>from the SWCs, as the app is being prepared to be shoveled into GCC. > >>That > >>would also require keeping some easy-to-understand data in each .JS file > >>so we don't have to parse the ReflectionData. > >> > >>If we say "no", the keep-code-with-metadata only gets processed at > >>transpile-time, then the implementation is simpler. I'm going to try the > >>"no' approach first. > >> > >>-Alex > >> > > > >
