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