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 >
