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 > >>> > >>> > >
