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