You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2016/10/01 06:23:34 UTC
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
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" <gr...@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 <ah...@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" <gr...@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 <gr...@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" <ah...@adobe.com> wrote:
>> >>
>> >>>
>> >>>
>> >>> On 9/29/16, 11:36 PM, "Alex Harui" <ah...@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
>> >>>
>> >>>
>>
>>
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Josh Tynjala <jo...@gmail.com>.
This seems like a reasonable enough workaround. I really wish GCC weren't
always giving us so many issues. I know many of them are "by design", but
it gets frustrating very quickly.
- Josh
On Wed, Oct 5, 2016 at 9:26 AM, Alex Harui <ah...@adobe.com> wrote:
> So I replaced the @expose usage with @export on Accessors and looked into
> why things don't work when you do that. It probably is a bug in GCC, but
> I saw an article where GCC developers say that all static definitions are
> considered separate "globals" and not properties of something. It is an
> interesting philosophy: that statics are just groupings of global
> variables. Thus I think it is not obvious to GCC that a property defined
> in the Object.defineProperty structure is the same one being referenced by
> other code. I don't see any annotations we can use to connect the
> defineProperty info to the class definition.
>
> In related GCC issues, the GCC authors recommend using obj['someProp']
> instead of @export. There as also another article about how property
> names in Object.defineProperty aren't going to get renamed anyway since
> they are referenced as strings or as keys in the Object.defineProperties
> structure. So, I've tested out a change to the compiler where any access
> to a static accessor (and only static accessors since instance accessors
> don't have this problem) will be done via obj['someProp'] instead of
> obj.someProp. Yes, that makes the code a bit uglier, but it seems to solve
> this problem.
>
> That's actually a nice advantage of having a compiler. We can write our
> code using obj.someProp and the compiler can output something else more
> suitable for GCC.
>
> Anyway, I wanted to see if anyone objects to this change before I push it.
> I'm about to start to propagate this change through the unit tests before
> committing.
>
> Thoughts?
> -Alex
>
> On 10/3/16, 10:58 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
> >I pushed changes to generate exportSymbol/exportProperty for certain
> >metadata names. It fixed the ReflectionTests in GenericTests.
> >
> >I also modified ObservedBugs so that it wouldn't get optimized away. IMO,
> >folks will just have to realize that certain patterns can be optimized
> >away. It might be possible to use the @throws jsdoc annotation as well,
> >but I'll leave that for someone else to try.
> >
> >Next up, undo the @expose for accessors and see if there is an alternative
> >solution.
> >
> >-Alex
> >
> >On 10/3/16, 11:07 AM, "Alex Harui" <ah...@adobe.com> wrote:
> >
> >>
> >>
> >>On 10/3/16, 10:51 AM, "Greg Dove" <gr...@gmail.com> wrote:
> >>
> >>>That sounds great Alex. Good sleuthing. As keep as3 metadata provides
> >>>for
> >>>specific metadata don't you think this could be default for the class
> >>>members with specific kept metadata? Given that the only reason for
> >>>keeping
> >>>it would be for reflection, I mean? I will be happy with the option here
> >>>no
> >>>matter how it is implemented though. Thanks!
> >>
> >>Not sure I understood what you meant.
> >>
> >>The default set of keep-as3-metadata includes things like [Bindable] and
> >>I
> >>think we want to allow unused [Bindable] properties to be removed by
> >>default. I think the set of keep-code-with-metadata we ship could be
> >>empty or include some FlexUnit metadata.
> >>
> >>In trying to implement this, there is an interesting issue. If we
> >>process
> >>keep-code-with-metadata in COMPJSC when cross-compiling a library, then
> >>you might end up with exportProperty calls in the .JS files and later
> >>when
> >>you use that library in building an app, we have to decide whether the
> >>keep-code-with-metadata assigned to the MXMLJSC run should also apply to
> >>the JS files it is linking to. If "yes", then we need to keep around
> >>data
> >>about why an exportProperty is in a JS file from COMPJSC so we can prune
> >>stuff out. Or we have MXMLJSC, but not COMPJSC, scan all .JS files, even
> >>from the SWCs, as the app is being prepared to be shoveled into GCC.
> >>That
> >>would also require keeping some easy-to-understand data in each .JS file
> >>so we don't have to parse the ReflectionData.
> >>
> >>If we say "no", the keep-code-with-metadata only gets processed at
> >>transpile-time, then the implementation is simpler. I'm going to try the
> >>"no' approach first.
> >>
> >>-Alex
> >>
> >
>
>
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Alex Harui <ah...@adobe.com>.
On 10/5/16, 11:13 AM, "Harbs" <ha...@gmail.com> wrote:
>And what’s the reason we’re not just using Foo.someOtherStaticProperty?
>Is this a getter issue?
Getters/Setters need to be defined via Object.defineProperty. It is the
only way to access a function via a property name (without using
parentheses). IOW
function Foo() {} // defines the class
Foo.someMethod = function() // defines a method.
Foo.someVar; // defines a var or const.
But when you use them, you have to write:
Foo.someMethod() // note the parenthesis for function call
Or
Foo.someVar // but no function will be called.
We want getters and setters to be accessed like:
Foo.someGetter; // calls a function
instead of:
Foo.someGetter();
So, we create an Object.defineProperties structure that looks like:
{ someGetter: { get: // the code that would run }}
Once you do that, when scanning Foo for vars and methods, GCC will not see
these getters and setters so it will not think that Foo has a someGetter
property. GCC is only looking for the pattern of Foo.someMethod =
function and Foo.someVar = initialValue;
So then when you use someGetter as
var value = Foo.someGetter;
GCC just renames it to a global like:
var value = xx;
And thus, the someGetter code is never called.
HTH,
-Alex
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)
Posted by Harbs <ha...@gmail.com>.
And what’s the reason we’re not just using Foo.someOtherStaticProperty? Is this a getter issue?
On Oct 5, 2016, at 9:08 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 10/5/16, 10:43 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> I have not been following this discussion very well, so I’m not sure I
>> got the issue, but will this prevent optimization of minimized code which
>> accesses static properties?
>
> I think I have discovered that static getters/setters were never getting
> renamed anyway. That's because if you have:
>
> public class Foo {
> public static function get bar():String
>
> It becomes:
>
> Object.defineProperty(Foo, { bar : function ... }
>
> And thus "bar" is a key in an Object and GCC doesn't try to rename those.
>
> Josh tried using @expose, which also prevented renaming as well, but we
> want to avoid using deprecated jsdoc tags.
>
> So, I think the final minified code in js-release is the same whether we
> are using @expose or this proposed change, but if you work with the
> js-debug code you will see:
>
> Foo["bar"]
>
> instead of
>
> Foo.bar
>
> FWIW, with just plain @export, the problem is that when setting up the
> renamed list for a class, GCC seems to only look at the code that looks
> like:
>
> /**
> * @type {string}
> */
> Foo.someOtherStaticProperty;
>
> and doesn't understand the Object.defineProperty call, so it doesn't think
> there is a "bar" property on Foo at all. So then, it optimizes
>
> Foo.bar
>
> to just a global like:
>
> xx
>
> HTH,
> -Alex
>
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Alex Harui <ah...@adobe.com>.
On 10/5/16, 11:10 AM, "Harbs" <ha...@gmail.com> wrote:
>So, this is only an issue for static functions and vars? Constants should
>be fine. Right?
Actually, only for static getters and setters. The output for vars,
consts and functions are not being changed at all and GCC will rename them
and set up aliases for them, which seems to work fine, because GCC will
use the same new variable name for all references to the static var,
const, or function, since they are declared via the standard:
Class.someStaticVarConstOrFunction = ...
GCC does not understand that getter/setter names in the
Object.defineProperties structure we use in our output also belongs to the
same class so it picks a new variable name and thus the getter/setter
don't get called.
HTH,
-Alex
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)
Posted by Harbs <ha...@gmail.com>.
So, this is only an issue for static functions and vars? Constants should be fine. Right?
On Oct 5, 2016, at 9:08 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 10/5/16, 10:43 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> I have not been following this discussion very well, so I’m not sure I
>> got the issue, but will this prevent optimization of minimized code which
>> accesses static properties?
>
> I think I have discovered that static getters/setters were never getting
> renamed anyway. That's because if you have:
>
> public class Foo {
> public static function get bar():String
>
> It becomes:
>
> Object.defineProperty(Foo, { bar : function ... }
>
> And thus "bar" is a key in an Object and GCC doesn't try to rename those.
>
> Josh tried using @expose, which also prevented renaming as well, but we
> want to avoid using deprecated jsdoc tags.
>
> So, I think the final minified code in js-release is the same whether we
> are using @expose or this proposed change, but if you work with the
> js-debug code you will see:
>
> Foo["bar"]
>
> instead of
>
> Foo.bar
>
> FWIW, with just plain @export, the problem is that when setting up the
> renamed list for a class, GCC seems to only look at the code that looks
> like:
>
> /**
> * @type {string}
> */
> Foo.someOtherStaticProperty;
>
> and doesn't understand the Object.defineProperty call, so it doesn't think
> there is a "bar" property on Foo at all. So then, it optimizes
>
> Foo.bar
>
> to just a global like:
>
> xx
>
> HTH,
> -Alex
>
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Alex Harui <ah...@adobe.com>.
On 10/5/16, 10:43 AM, "Harbs" <ha...@gmail.com> wrote:
>I have not been following this discussion very well, so I’m not sure I
>got the issue, but will this prevent optimization of minimized code which
>accesses static properties?
I think I have discovered that static getters/setters were never getting
renamed anyway. That's because if you have:
public class Foo {
public static function get bar():String
It becomes:
Object.defineProperty(Foo, { bar : function ... }
And thus "bar" is a key in an Object and GCC doesn't try to rename those.
Josh tried using @expose, which also prevented renaming as well, but we
want to avoid using deprecated jsdoc tags.
So, I think the final minified code in js-release is the same whether we
are using @expose or this proposed change, but if you work with the
js-debug code you will see:
Foo["bar"]
instead of
Foo.bar
FWIW, with just plain @export, the problem is that when setting up the
renamed list for a class, GCC seems to only look at the code that looks
like:
/**
* @type {string}
*/
Foo.someOtherStaticProperty;
and doesn't understand the Object.defineProperty call, so it doesn't think
there is a "bar" property on Foo at all. So then, it optimizes
Foo.bar
to just a global like:
xx
HTH,
-Alex
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)
Posted by Harbs <ha...@gmail.com>.
I have not been following this discussion very well, so I’m not sure I got the issue, but will this prevent optimization of minimized code which accesses static properties?
On Oct 5, 2016, at 7:26 PM, Alex Harui <ah...@adobe.com> wrote:
> Anyway, I wanted to see if anyone objects to this change before I push it.
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Alex Harui <ah...@adobe.com>.
So I replaced the @expose usage with @export on Accessors and looked into
why things don't work when you do that. It probably is a bug in GCC, but
I saw an article where GCC developers say that all static definitions are
considered separate "globals" and not properties of something. It is an
interesting philosophy: that statics are just groupings of global
variables. Thus I think it is not obvious to GCC that a property defined
in the Object.defineProperty structure is the same one being referenced by
other code. I don't see any annotations we can use to connect the
defineProperty info to the class definition.
In related GCC issues, the GCC authors recommend using obj['someProp']
instead of @export. There as also another article about how property
names in Object.defineProperty aren't going to get renamed anyway since
they are referenced as strings or as keys in the Object.defineProperties
structure. So, I've tested out a change to the compiler where any access
to a static accessor (and only static accessors since instance accessors
don't have this problem) will be done via obj['someProp'] instead of
obj.someProp. Yes, that makes the code a bit uglier, but it seems to solve
this problem.
That's actually a nice advantage of having a compiler. We can write our
code using obj.someProp and the compiler can output something else more
suitable for GCC.
Anyway, I wanted to see if anyone objects to this change before I push it.
I'm about to start to propagate this change through the unit tests before
committing.
Thoughts?
-Alex
On 10/3/16, 10:58 PM, "Alex Harui" <ah...@adobe.com> wrote:
>I pushed changes to generate exportSymbol/exportProperty for certain
>metadata names. It fixed the ReflectionTests in GenericTests.
>
>I also modified ObservedBugs so that it wouldn't get optimized away. IMO,
>folks will just have to realize that certain patterns can be optimized
>away. It might be possible to use the @throws jsdoc annotation as well,
>but I'll leave that for someone else to try.
>
>Next up, undo the @expose for accessors and see if there is an alternative
>solution.
>
>-Alex
>
>On 10/3/16, 11:07 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>
>>
>>On 10/3/16, 10:51 AM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>>>That sounds great Alex. Good sleuthing. As keep as3 metadata provides
>>>for
>>>specific metadata don't you think this could be default for the class
>>>members with specific kept metadata? Given that the only reason for
>>>keeping
>>>it would be for reflection, I mean? I will be happy with the option here
>>>no
>>>matter how it is implemented though. Thanks!
>>
>>Not sure I understood what you meant.
>>
>>The default set of keep-as3-metadata includes things like [Bindable] and
>>I
>>think we want to allow unused [Bindable] properties to be removed by
>>default. I think the set of keep-code-with-metadata we ship could be
>>empty or include some FlexUnit metadata.
>>
>>In trying to implement this, there is an interesting issue. If we
>>process
>>keep-code-with-metadata in COMPJSC when cross-compiling a library, then
>>you might end up with exportProperty calls in the .JS files and later
>>when
>>you use that library in building an app, we have to decide whether the
>>keep-code-with-metadata assigned to the MXMLJSC run should also apply to
>>the JS files it is linking to. If "yes", then we need to keep around
>>data
>>about why an exportProperty is in a JS file from COMPJSC so we can prune
>>stuff out. Or we have MXMLJSC, but not COMPJSC, scan all .JS files, even
>>from the SWCs, as the app is being prepared to be shoveled into GCC.
>>That
>>would also require keeping some easy-to-understand data in each .JS file
>>so we don't have to parse the ReflectionData.
>>
>>If we say "no", the keep-code-with-metadata only gets processed at
>>transpile-time, then the implementation is simpler. I'm going to try the
>>"no' approach first.
>>
>>-Alex
>>
>
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Alex Harui <ah...@adobe.com>.
I pushed changes to generate exportSymbol/exportProperty for certain
metadata names. It fixed the ReflectionTests in GenericTests.
I also modified ObservedBugs so that it wouldn't get optimized away. IMO,
folks will just have to realize that certain patterns can be optimized
away. It might be possible to use the @throws jsdoc annotation as well,
but I'll leave that for someone else to try.
Next up, undo the @expose for accessors and see if there is an alternative
solution.
-Alex
On 10/3/16, 11:07 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 10/3/16, 10:51 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
>>That sounds great Alex. Good sleuthing. As keep as3 metadata provides for
>>specific metadata don't you think this could be default for the class
>>members with specific kept metadata? Given that the only reason for
>>keeping
>>it would be for reflection, I mean? I will be happy with the option here
>>no
>>matter how it is implemented though. Thanks!
>
>Not sure I understood what you meant.
>
>The default set of keep-as3-metadata includes things like [Bindable] and I
>think we want to allow unused [Bindable] properties to be removed by
>default. I think the set of keep-code-with-metadata we ship could be
>empty or include some FlexUnit metadata.
>
>In trying to implement this, there is an interesting issue. If we process
>keep-code-with-metadata in COMPJSC when cross-compiling a library, then
>you might end up with exportProperty calls in the .JS files and later when
>you use that library in building an app, we have to decide whether the
>keep-code-with-metadata assigned to the MXMLJSC run should also apply to
>the JS files it is linking to. If "yes", then we need to keep around data
>about why an exportProperty is in a JS file from COMPJSC so we can prune
>stuff out. Or we have MXMLJSC, but not COMPJSC, scan all .JS files, even
>from the SWCs, as the app is being prepared to be shoveled into GCC. That
>would also require keeping some easy-to-understand data in each .JS file
>so we don't have to parse the ReflectionData.
>
>If we say "no", the keep-code-with-metadata only gets processed at
>transpile-time, then the implementation is simpler. I'm going to try the
>"no' approach first.
>
>-Alex
>
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Alex Harui <ah...@adobe.com>.
On 10/3/16, 10:51 AM, "Greg Dove" <gr...@gmail.com> wrote:
>That sounds great Alex. Good sleuthing. As keep as3 metadata provides for
>specific metadata don't you think this could be default for the class
>members with specific kept metadata? Given that the only reason for
>keeping
>it would be for reflection, I mean? I will be happy with the option here
>no
>matter how it is implemented though. Thanks!
Not sure I understood what you meant.
The default set of keep-as3-metadata includes things like [Bindable] and I
think we want to allow unused [Bindable] properties to be removed by
default. I think the set of keep-code-with-metadata we ship could be
empty or include some FlexUnit metadata.
In trying to implement this, there is an interesting issue. If we process
keep-code-with-metadata in COMPJSC when cross-compiling a library, then
you might end up with exportProperty calls in the .JS files and later when
you use that library in building an app, we have to decide whether the
keep-code-with-metadata assigned to the MXMLJSC run should also apply to
the JS files it is linking to. If "yes", then we need to keep around data
about why an exportProperty is in a JS file from COMPJSC so we can prune
stuff out. Or we have MXMLJSC, but not COMPJSC, scan all .JS files, even
from the SWCs, as the app is being prepared to be shoveled into GCC. That
would also require keeping some easy-to-understand data in each .JS file
so we don't have to parse the ReflectionData.
If we say "no", the keep-code-with-metadata only gets processed at
transpile-time, then the implementation is simpler. I'm going to try the
"no' approach first.
-Alex
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Greg Dove <gr...@gmail.com>.
That sounds great Alex. Good sleuthing. As keep as3 metadata provides for
specific metadata don't you think this could be default for the class
members with specific kept metadata? Given that the only reason for keeping
it would be for reflection, I mean? I will be happy with the option here no
matter how it is implemented though. Thanks!
-Greg
[sent from my phone]
On 4/10/2016 4:09 AM, "Alex Harui" <ah...@adobe.com> wrote:
> Update: Turns out that FalconJX already calls GCC with
> --generate-exports, and methods are being exported in the js-release
> version. What it looks like to me is that for the one case I am debugging
> (ReflectionTesterTest), the setUpBeforeClass method is removed by GCC dead
> code removal since there is no obvious code path that calls it. The test
> runner sees that setUpBeforeClass is listed as the [BeforeClass] method
> but can't find the method and just assigns undefined as the
> beforeClassFunc. The runner then doesn't call any beforeClassFunc so the
> test is not set up properly and fails. The runner could detect this
> condition and report an error, but fundamentally, we need to keep certain
> methods from being removed.
>
> IOW, using @export doesn't prevent a method from being removed by dead
> code removal. From the GCC doc, if we generated our own function calls to
> exportSymbol/exportProperty, it would prevent the method from being
> removed. So, I am now off to teach FalconJX to generate more
> exportSymbol/exportProperty calls (FalconJX already generates one
> exportSymbol for the class definition).
>
> Again, I do not want to generate exportSymbol for every public property.
> I think we want to use @export and allow for dead code removal most of the
> time. My plan is to add an option similar to -keep-as3-metadata. I am
> going to call it -keep-code-with-metadata for now. Any methods annotated
> with a metadata name in that list will have an exportSymbol or
> exportProperty generated for it. A simpler option is to require folks to
> add some sort of @dontremove directive or metadata to their code, but that
> would be painful to update existing code bases.
>
> Thoughts?
> -Alex
>
> On 10/1/16, 10:11 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
> >
> >
> >On 10/1/16, 12:37 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >
> >>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.
> >
> >AIUI, the use of @export doesn't do anything until you turn on
> >--generate-exports. But then, it export every public API in the entire
> >app, which is probably not what you want.
> >
>
>
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Alex Harui <ah...@adobe.com>.
Update: Turns out that FalconJX already calls GCC with
--generate-exports, and methods are being exported in the js-release
version. What it looks like to me is that for the one case I am debugging
(ReflectionTesterTest), the setUpBeforeClass method is removed by GCC dead
code removal since there is no obvious code path that calls it. The test
runner sees that setUpBeforeClass is listed as the [BeforeClass] method
but can't find the method and just assigns undefined as the
beforeClassFunc. The runner then doesn't call any beforeClassFunc so the
test is not set up properly and fails. The runner could detect this
condition and report an error, but fundamentally, we need to keep certain
methods from being removed.
IOW, using @export doesn't prevent a method from being removed by dead
code removal. From the GCC doc, if we generated our own function calls to
exportSymbol/exportProperty, it would prevent the method from being
removed. So, I am now off to teach FalconJX to generate more
exportSymbol/exportProperty calls (FalconJX already generates one
exportSymbol for the class definition).
Again, I do not want to generate exportSymbol for every public property.
I think we want to use @export and allow for dead code removal most of the
time. My plan is to add an option similar to -keep-as3-metadata. I am
going to call it -keep-code-with-metadata for now. Any methods annotated
with a metadata name in that list will have an exportSymbol or
exportProperty generated for it. A simpler option is to require folks to
add some sort of @dontremove directive or metadata to their code, but that
would be painful to update existing code bases.
Thoughts?
-Alex
On 10/1/16, 10:11 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>On 10/1/16, 12:37 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
>>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.
>
>AIUI, the use of @export doesn't do anything until you turn on
>--generate-exports. But then, it export every public API in the entire
>app, which is probably not what you want.
>
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Alex Harui <ah...@adobe.com>.
On 10/1/16, 12:37 PM, "Greg Dove" <gr...@gmail.com> wrote:
>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.
AIUI, the use of @export doesn't do anything until you turn on
--generate-exports. But then, it export every public API in the entire
app, which is probably not what you want.
Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript
language feature: Optionally rename an import)
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@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" <gr...@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 <ah...@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" <gr...@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 <gr...@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" <ah...@adobe.com> wrote:
> >> >>
> >> >>>
> >> >>>
> >> >>> On 9/29/16, 11:36 PM, "Alex Harui" <ah...@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
> >> >>>
> >> >>>
> >>
> >>
>
>