Sorry I did not have time to read up on this yet. If --generate-exports can somehow restore that naming retention for public static members annotated with '@export' then that will be a great starting point as an option to switch this on or off when needed.
If I consider where I have used refllection in mainstream apps in the past it was mostly for access to the instance members I think, either in code I wrote myself or in the libraries used in the project (e.g. depedency injection support with RobotLegs). The other main area here is for serialization/deserialization, which again focuses on (a subset of) instance members. I can't offhand think of a mainstream reason to want to reflect into static members, aside from needing a) to test the ability to do so or b) some sort of highly reflective analysis of code added into a project for some debugging or external reporting purposes, which could perhaps be useful during development. But I also confess to not having given it a lot of thought outside of wanting to 'get it done'. My main goal with work on this so far was to try to get the exact same code setup for flexunit working in js as well, so that we could run them side by side and then potentially drop the same test into the CI build (which would only run in swf for now). The reason for this ramble is that I cannot think of a reason for a need for individual class or member based variation needed here for statics (unless you think this affects bindable statics too?), but perhaps you have some in mind that I did not think of. Regardless, I think if it is possible to do that, then I think most people would prefer the possibility to fine-tune things as well. On Sat, Oct 1, 2016 at 7:23 PM, Alex Harui <aha...@adobe.com> wrote: > Change GoogDocEmitter got rid of the warnings but broke GenericTests for > now. > > I will next try --generate-exports, but I'm thinking we want to allow > control at the file and property/method level. > > Thoughts? > -Alex > > On 9/30/16, 12:27 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > >Thanks for the explanation! > >I guess I missed the distinction with the accessors, but I had remembered > >the 'solution' and just assumed it was appropriate when it 'worked' for > >static variables and methods (not realizing the other consequences). > > > >In any case it appears that @export does not prevent renaming on the > >static > >members, but it seems it currently does on instance members. > >If you find a solution for statics while I'm away that would be great. > >--generate_exports > >sounds like a possible option (for reflection and/or bindable needs) if it > >works. > > > >Otherwise I am happy to dig in when I'm back. > > > > > >On Sat, Oct 1, 2016 at 8:07 AM, Alex Harui <aha...@adobe.com> wrote: > > > >> IMO, there are two separate issues. > >> > >> I think Josh found that static accessors couldn't be accessed via normal > >> code "ClassName.propertyName". I ran into this for instance accessors > >>as > >> well. The instance accessors are defined in a Object.defineProperty > >>call > >> separate from the usual ClassName.prototype.propertyName syntax. GCC > >> should be able to rename propertyName to "a" as long as it renames the > >> accessor name to "a" as well, but GCC was being fooled since the > >>accessor > >> doesn't follow the standard pattern and would choose "b" instead. I > >>will > >> have to investigate to see how I fixed this for instance accessors and > >>see > >> if similar approaches will work for static accessors. IOW, we need to > >> sync up the renaming between the accessors and the rest of the class. > >> > >> Reflection, IMO, is a separate issue. I think Binding has similar > >>issues. > >> There, we might be using dot-path string expressions and trying to find > >> them, but they’ve been renamed. SO this is either syncing up strings to > >> the rename, or preventing the rename in the first place. What we want > >>to > >> allow is for projects that don't use Reflection (and Binding) to get the > >> benefits of renaming to shorter names. Then Reflection and Binding may > >> require that you make your app fatter by preventing certain renames or > >> maybe we'll find a way to figure out what the rename was and change the > >> string used for lookup. > >> > >> Hard to say what the answer will be right now. My first move is to > >>revert > >> each change from @expose back to @export and see what breaks and if one > >>of > >> those changes makes all of those warnings go away. Then look into new > >> solutions. See mention of the --generate_exports in [2]. It looks like > >> we aren't using it, and we might make that option required for > >>Reflection, > >> although it could seriously bloat the output. > >> > >> -Alex > >> > >> [2] > >> https://github.com/google/closure-compiler/wiki/ > >> Annotating-JavaScript-for-t > >> he-Closure-Compiler > >> > >> On 9/30/16, 11:37 AM, "Greg Dove" <greg.d...@gmail.com> wrote: > >> > >> >I read that link, it's very helpful. It seems that this is going to be > >>a > >> >challenge. I suggest you revert that as you suggested. > >> > > >> >Josh discovered this originally for static accessors I think (the fact > >> >that > >> >@export does not prevent renaming on statics and @expose was the only > >> >other > >> >option that seemed to work). I 'rediscovered' it when I was working on > >> >static bindables. Then it became obvious it also affected static > >>variables > >> >and methods when I tested for reflection. > >> > > >> >The advice in that note is similar to what I think you were mentioning > >> >elsewhere about string access. > >> > > >> >"If you want a property not to be obfuscated, access it as > >> >this['sample']instead of this.sample (you'll also need to fix all > >> >references)." (instead of using @expose) > >> > > >> >Go ahead and revert that change and I can see what (if anything) I can > >>do > >> >with the above when I'm back. > >> > > >> > > >> > > >> > > >> >On Sat, Oct 1, 2016 at 6:53 AM, Greg Dove <greg.d...@gmail.com> wrote: > >> > > >> >> Alex, @export did not work for me on any static members. You cannot > >> >> reflect into the field names unless you use @expose. > >> >> > >> >> You can double check this via generictests reflection tests. > >> >> > >> >> -Greg > >> >> [sent from my phone] > >> >> > >> >> On 1/10/2016 5:21 AM, "Alex Harui" <aha...@adobe.com> wrote: > >> >> > >> >>> > >> >>> > >> >>> On 9/29/16, 11:36 PM, "Alex Harui" <aha...@adobe.com> wrote: > >> >>> > > >> >>> >Now that I got rid of the circularity in Ibead/Istrand I am also > >> >>>getting > >> >>> a > >> >>> >ton of warnings that say: > >> >>> > > >> >>> > WARNING - incomplete alias created for namespace goog > >> >>> > >> >>> I think is is being caused by the change from @export to @expose [1] > >> >>> > >> >>> What was the scenario where @export wasn't working? I'm going to > >> >>>switch > >> >>> things back to @export > >> >>> > >> >>> -Alex > >> >>> > >> >>> [1] https://developers.google.com/closure/compiler/docs/error-ref > >> >>> > >> >>> > >> > >> > >
