flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)
Date Sat, 01 Oct 2016 06:23:34 GMT
Change GoogDocEmitter got rid of the warnings but broke GenericTests for

I will next try --generate-exports, but I'm thinking we want to allow
control at the file and property/method level.


On 9/30/16, 12:27 PM, "Greg Dove" <greg.dove@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
>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.
>sounds like a possible option (for reflection and/or bindable needs) if it
>Otherwise I am happy to dig in when I'm back.
>On Sat, Oct 1, 2016 at 8:07 AM, Alex Harui <aharui@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
>> well.  The instance accessors are defined in a Object.defineProperty
>> 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
>> doesn't follow the standard pattern and would choose "b" instead.  I
>> have to investigate to see how I fixed this for instance accessors and
>> 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
>>  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
>> 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
>> each change from @expose back to @export and see what breaks and if one
>> 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
>> 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.dove@gmail.com> wrote:
>> >I read that link, it's very helpful. It seems that this is going to be
>> >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
>> >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
>> >with the above when I'm back.
>> >
>> >
>> >
>> >
>> >On Sat, Oct 1, 2016 at 6:53 AM, Greg Dove <greg.dove@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" <aharui@adobe.com> wrote:
>> >>
>> >>>
>> >>>
>> >>> On 9/29/16, 11:36 PM, "Alex Harui" <aharui@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
>> >>>
>> >>>

View raw message