Thanks for clarifying. I see that you mentioned that originally now :) I think if GCC is smart enough to follow the indirection between those reflection field names and all possible uses of reflection it would be quite impressive. I don't think it works as is, because if it wasn't for some static fields that had '@export' on them which I had to change to '@expose' to make them work, unless the original @export was preventing it working. I might do a quick check of this sometime in the next couple of weeks to see if I can remove some of the annotations and see whether it works or not.
I will check the deadcode elimination for relection info in helloworld today On Thu, Sep 29, 2016 at 7:25 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 9/28/16, 11:19 AM, "Greg Dove" <greg.d...@gmail.com> wrote: > > >I hadn't investigated any of this, just wondered about it I will check the > >reflection results today. > >I had actually assumed that @export and @expose explicitly prevented > >renaming, but also had not checked this. > > > > Maybe I wasn't clear. > > @export and @expose do prevent renaming. But so does certain uses of > string literals, so some day, if we make an option that sweeps away all of > the @exports and @exposes, we want to know if the copies of the method and > property names in FLEXJS_REFLECTION_INFO would also prevent renaming. > > No needed to investigate that until we get around to having a feature that > sweeps away @expose and @export, I just am hoping that > FLEXJS_REFLECTION_INFO is still seen as dead code to the Hello World app. > > Thanks, > -Alex > >
