Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui <ah...@adobe.com>]

On 9/28/16, 3:25 AM, "Harbs" <ha...@gmail.com> wrote:

>I like this idea and would propose taking it one step further:
>
>Currently transpiled javascript has fully qualified class names for
>pretty much everything. This is difficult for closure to minimize
>completely. I’d really like to have some way to “export” class names as
>well as “import” to define some compact name for packages. Based on my
>playing around, this could save at least tens of KB of JS downloads.

For sure, the amount of download for strings is a significant waste of
bytes in most cases.  However, I'm not sure we need to provide renaming
controls for folks building FlexJS apps, at least not for the mainstream.

AIUI, every public property and method in FlexJS is "exported" to prevent
renaming for a few "just-in-case" reasons.  First, a review of renaming:

FlexJS uses the Google Closure Compiler to optimize/minify the output JS
file.  In doing so, GCC tries to renaming variables.  For example, every
FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might rename
that property to just "a", so the original JS might look like:

    UIBase.prototype.FLEXJS_CLASS_INFO = {..};

But GCC will cause that to look like:

    UIBase.prototype.a = {..};

If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you can
save quite a bit of download size.  But then, what happens if someone
writes code that looks like:

    var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
    var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];

For the first line, GCC will know to alter the code to look like:

    var foo:Object = someUIBase.a;

And everything will work fine, but AIUI, GCC does not try to alter strings
so it will not touch the "bar" code and that would fail at runtime since
there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.


But I think that GCC is now smart enough that if you actually have a line
like the "bar" line, that will prevent GCC from renaming
FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that the
output must have the bytes for "FLEXJS_CLASS_INFO" once in order to honor
the string literal, so it will create an alias like aa =
"FLEXJS_CLASS_INFO" and then the code is output as:

    UIBase.prototype[aa] = {..};
And
    var foo:Object = someUIBase[aa];
    var bar:Object = someUIBase[aa];

IOW, GCC has a pretty good alias generator, which is why I don't think our
tool chain needs to provide folks with the manual options to rename.  We
should just let GCC do its thing.


So, AIUI, the reason we export every public thing isn't for the standard
dynamic access case as shown above, but for two others (and related
scenarios):
-Dynamic access using generated strings
-Binding expressions with "dot-paths"

Dynamic access using generated strings are scenarios where you know that
every property starts with "str_" and run code like:

   var foo:String = bar["str_" + i];

GCC isn't smart enough to handle this.

Dot-path Binding Expressions are where you want to use data binding to
bind to "myModel.subObject.someProperty".  GCC will just look at the
entire string and since it doesn't match any property it will rename
myModel and subObject and someProperty and the binding will fail at
runtime.

So, AIUI, we have huge string tables in our apps for these two cases even
though 99% or even 100% of the time, your app isn't going to access those
methods and properties in a way that GCC can't detect.  So, before we add
some user-controlled renaming, I think we should first explore a compiler
option like -no-rename where you guarantee that your app doesn't use
generated strings or dot-path binding expressions and we clear all the
@exports out of the code before sending it to GCC.

I'll bet somewhere in the framework we do use generated strings and will
have to fix that up, but I think that should be doable.  I think the
compiler could also output string literals with "." in them as separate
strings and that might solve the dot-path problem.  IOW, instead of simply
outputting "myModel.subObject.someProperty", the compiler would output:

  "myModel" + "." + "subObject" + "." + "someProperty"

I've also seen information that indicates we might be able to control or
provide hints to GCC about what it can rename such that a smarter FalconJX
could look for dynamic access and tell GCC not to rename properties in
classes it knows will be dynamically accesses and let GCC rename
everything else.

Volunteers are welcome to do more research on leveraging and controlling
GCC renaming.  I haven't made it a high priority for me.

My 2 cents,
-Alex

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui <ah...@adobe.com>]

On 9/28/16, 11:36 AM, "Greg Dove" <gr...@gmail.com> wrote:

>Thanks for clarifying. I see that you mentioned that originally now :)
>I think if GCC is smart enough to follow the indirection between those
>reflection field names and all possible uses of reflection it would be
>quite impressive. I don't think it works as is, because if it wasn't for
>some static fields that had '@export' on them which I had to change to
>'@expose' to make them work, unless the original @export was preventing it
>working. I might do a quick check of this sometime in the next couple of
>weeks to see if I can remove some of the annotations and see whether it
>works or not.

I agree that the reflection data is unlikely to prevent renaming.  But I
think you can do static code-flow analysis and potentially find that a
data structure is being used for dynamic access.

>
>I will check the deadcode elimination for relection info in helloworld
>today
>

Please see about fixing the flex-falcon build first.  I just passed the
buck to you on that thread a few minutes ago.

Thanks,
-Alex

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove <gr...@gmail.com>]

Thanks for clarifying. I see that you mentioned that originally now :)
I think if GCC is smart enough to follow the indirection between those
reflection field names and all possible uses of reflection it would be
quite impressive. I don't think it works as is, because if it wasn't for
some static fields that had '@export' on them which I had to change to
'@expose' to make them work, unless the original @export was preventing it
working. I might do a quick check of this sometime in the next couple of
weeks to see if I can remove some of the annotations and see whether it
works or not.

I will check the deadcode elimination for relection info in helloworld today



On Thu, Sep 29, 2016 at 7:25 AM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 9/28/16, 11:19 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
> >I hadn't investigated any of this, just wondered about it I will check the
> >reflection results today.
> >I had actually assumed that @export and @expose explicitly prevented
> >renaming, but also had not checked this.
> >
>
> Maybe I wasn't clear.
>
> @export and @expose do prevent renaming.  But so does certain uses of
> string literals, so some day, if we make an option that sweeps away all of
> the @exports and @exposes, we want to know if the copies of the method and
> property names in FLEXJS_REFLECTION_INFO would also prevent renaming.
>
> No needed to investigate that until we get around to having a feature that
> sweeps away @expose and @export, I just am hoping that
> FLEXJS_REFLECTION_INFO is still seen as dead code to the Hello World app.
>
> Thanks,
> -Alex
>
>

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui <ah...@adobe.com>]

On 9/28/16, 11:19 AM, "Greg Dove" <gr...@gmail.com> wrote:

>I hadn't investigated any of this, just wondered about it I will check the
>reflection results today.
>I had actually assumed that @export and @expose explicitly prevented
>renaming, but also had not checked this.
>

Maybe I wasn't clear.

@export and @expose do prevent renaming.  But so does certain uses of
string literals, so some day, if we make an option that sweeps away all of
the @exports and @exposes, we want to know if the copies of the method and
property names in FLEXJS_REFLECTION_INFO would also prevent renaming.

No needed to investigate that until we get around to having a feature that
sweeps away @expose and @export, I just am hoping that
FLEXJS_REFLECTION_INFO is still seen as dead code to the Hello World app.

Thanks,
-Alex

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui <ah...@adobe.com>]

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)

[Greg Dove <gr...@gmail.com>]

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)

[Alex Harui <ah...@adobe.com>]

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)

[Greg Dove <gr...@gmail.com>]

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)

[Greg Dove <gr...@gmail.com>]

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)

[Alex Harui <ah...@adobe.com>]

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)

[Alex Harui <ah...@adobe.com>]

On 9/28/16, 11:43 AM, "Alex Harui" <ah...@adobe.com> wrote:

>
>
>On 9/28/16, 11:23 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
>>OT: I am getting a lot of warnings in the GCC release build phase. I
>>recall
>>you mentioning something in the past about this being related to GCC
>>versions - is there anything I can do to address this?

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

IIRC, that isn't a GCC/GCL mismatch.  I think it means the generated code
has a global "goog" variable or something like that.  I guess that'll be
my task for tomorrow.

-Alex

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui <ah...@adobe.com>]

On 9/28/16, 11:23 AM, "Greg Dove" <gr...@gmail.com> wrote:

>OT: I am getting a lot of warnings in the GCC release build phase. I
>recall
>you mentioning something in the past about this being related to GCC
>versions - is there anything I can do to address this?

Every once in a while, we have to upgrade to the latest GCC and GCL
together.

The GCC is determined by the compiler-jx/src/main/resources/downloads.xml
build script in flex-falcon.  I think we always pull the latest GCL, so
maybe just try updating GCC.  If you look at source code history you might
find other things that had to change when we upgrade.  Depending on your
setup, your copy of GCL might be stale and not refreshed by the build so
you may need to delete your GCL.

Also, I think the version of GCC is set in a pom.xml somewhere for Maven.

There is also a chance that the compiler needs to change its codeine.

HTH,
-Alex

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove <gr...@gmail.com>]

OT: I am getting a lot of warnings in the GCC release build phase. I recall
you mentioning something in the past about this being related to GCC
versions - is there anything I can do to address this?



On Thu, Sep 29, 2016 at 7:19 AM, Greg Dove <gr...@gmail.com> wrote:

> I hadn't investigated any of this, just wondered about it I will check the
> reflection results today.
> I had actually assumed that @export and @expose explicitly prevented
> renaming, but also had not checked this.
>
>
>
>
> On Thu, Sep 29, 2016 at 7:13 AM, Alex Harui <ah...@adobe.com> wrote:
>
>> In fact, when I last touched it, Reflection was optional.  Unless you
>> actually use a reflection API (whose code path access
>> FLEXJS_REFLECTION_INFO), GCC did not output FLEXJS_REFLECTION_INFO in the
>> minified results.  Probably worth verifying that is still true.
>>
>> What I don't know is whether dead code is removed before renaming.  I hope
>> so (and it makes sense to do it that way), otherwise the strings in
>> FLEXJS_REFLECTION_INFO may prevent renaming.
>>
>> All that is part of Pay-as-you-go.  A related goal is to make the "opt-in"
>> automatic.  IOW, we don't want folks to have to set compiler options to
>> get features. They should come in as you use the APIs.
>>
>> -Alex
>>
>> On 9/28/16, 11:05 AM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>> > "reflection support could be opt-in (or opt-out)"
>> >
>> >On reflection (pun unintended) maybe that is not sensible, given it is
>> >baked in to the framework classes. If GCC does dead-code elimination,
>> >maybe
>> >that does the job anyhow.
>> >
>> >
>> >
>> >On Thu, Sep 29, 2016 at 7:02 AM, Greg Dove <gr...@gmail.com> wrote:
>> >
>> >> Alex, I had also considered the same idea of doing the qualifiedName
>> >> splitting in the reflection data because I think you would reduce a lot
>> >>of
>> >> long string variation in the GCC release build simply by doing
>> >> 'org.apache.flex.'+'Package.'+'ClassName' etc
>> >>
>> >> Isn't using the reflection member definition names for access also
>> >>another
>> >> use that would qualify as 'dynamic' access? I am not sure if GCC can
>> >>make
>> >> the connection between the reflection data field names and the original
>> >> naming of the fields which is why we need @export on instance members
>> >>and
>> >> @expose on static members (without those it fails iirc).
>> >>
>> >> One option for the future might be to make Reflection support optional.
>> >>I
>> >> think we might still want FLEXJS_CLASS_INFO, but perhaps the rest of
>> the
>> >> the reflection support could be opt-in (or opt-out). This alone could
>> >> reduce a lot of code for people who don't need that.
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Sep 29, 2016 at 6:17 AM, Alex Harui <ah...@adobe.com> wrote:
>> >>
>> >>>
>> >>>
>> >>> On 9/28/16, 3:25 AM, "Harbs" <ha...@gmail.com> wrote:
>> >>>
>> >>> >I like this idea and would propose taking it one step further:
>> >>> >
>> >>> >Currently transpiled javascript has fully qualified class names for
>> >>> >pretty much everything. This is difficult for closure to minimize
>> >>> >completely. I’d really like to have some way to “export” class names
>> >>>as
>> >>> >well as “import” to define some compact name for packages. Based on
>> my
>> >>> >playing around, this could save at least tens of KB of JS downloads.
>> >>>
>> >>> For sure, the amount of download for strings is a significant waste of
>> >>> bytes in most cases.  However, I'm not sure we need to provide
>> renaming
>> >>> controls for folks building FlexJS apps, at least not for the
>> >>>mainstream.
>> >>>
>> >>> AIUI, every public property and method in FlexJS is "exported" to
>> >>>prevent
>> >>> renaming for a few "just-in-case" reasons.  First, a review of
>> >>>renaming:
>> >>>
>> >>> FlexJS uses the Google Closure Compiler to optimize/minify the output
>> >>>JS
>> >>> file.  In doing so, GCC tries to renaming variables.  For example,
>> >>>every
>> >>> FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might
>> >>>rename
>> >>> that property to just "a", so the original JS might look like:
>> >>>
>> >>>     UIBase.prototype.FLEXJS_CLASS_INFO = {..};
>> >>>
>> >>> But GCC will cause that to look like:
>> >>>
>> >>>     UIBase.prototype.a = {..};
>> >>>
>> >>> If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you
>> >>>can
>> >>> save quite a bit of download size.  But then, what happens if someone
>> >>> writes code that looks like:
>> >>>
>> >>>     var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
>> >>>     var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];
>> >>>
>> >>> For the first line, GCC will know to alter the code to look like:
>> >>>
>> >>>     var foo:Object = someUIBase.a;
>> >>>
>> >>> And everything will work fine, but AIUI, GCC does not try to alter
>> >>>strings
>> >>> so it will not touch the "bar" code and that would fail at runtime
>> >>>since
>> >>> there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.
>> >>>
>> >>>
>> >>> But I think that GCC is now smart enough that if you actually have a
>> >>>line
>> >>> like the "bar" line, that will prevent GCC from renaming
>> >>> FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that
>> >>>the
>> >>> output must have the bytes for "FLEXJS_CLASS_INFO" once in order to
>> >>>honor
>> >>> the string literal, so it will create an alias like aa =
>> >>> "FLEXJS_CLASS_INFO" and then the code is output as:
>> >>>
>> >>>     UIBase.prototype[aa] = {..};
>> >>> And
>> >>>     var foo:Object = someUIBase[aa];
>> >>>     var bar:Object = someUIBase[aa];
>> >>>
>> >>> IOW, GCC has a pretty good alias generator, which is why I don't think
>> >>>our
>> >>> tool chain needs to provide folks with the manual options to rename.
>> >>>We
>> >>> should just let GCC do its thing.
>> >>>
>> >>>
>> >>> So, AIUI, the reason we export every public thing isn't for the
>> >>>standard
>> >>> dynamic access case as shown above, but for two others (and related
>> >>> scenarios):
>> >>> -Dynamic access using generated strings
>> >>> -Binding expressions with "dot-paths"
>> >>>
>> >>> Dynamic access using generated strings are scenarios where you know
>> >>>that
>> >>> every property starts with "str_" and run code like:
>> >>>
>> >>>    var foo:String = bar["str_" + i];
>> >>>
>> >>> GCC isn't smart enough to handle this.
>> >>>
>> >>> Dot-path Binding Expressions are where you want to use data binding to
>> >>> bind to "myModel.subObject.someProperty".  GCC will just look at the
>> >>> entire string and since it doesn't match any property it will rename
>> >>> myModel and subObject and someProperty and the binding will fail at
>> >>> runtime.
>> >>>
>> >>> So, AIUI, we have huge string tables in our apps for these two cases
>> >>>even
>> >>> though 99% or even 100% of the time, your app isn't going to access
>> >>>those
>> >>> methods and properties in a way that GCC can't detect.  So, before we
>> >>>add
>> >>> some user-controlled renaming, I think we should first explore a
>> >>>compiler
>> >>> option like -no-rename where you guarantee that your app doesn't use
>> >>> generated strings or dot-path binding expressions and we clear all the
>> >>> @exports out of the code before sending it to GCC.
>> >>>
>> >>> I'll bet somewhere in the framework we do use generated strings and
>> >>>will
>> >>> have to fix that up, but I think that should be doable.  I think the
>> >>> compiler could also output string literals with "." in them as
>> separate
>> >>> strings and that might solve the dot-path problem.  IOW, instead of
>> >>>simply
>> >>> outputting "myModel.subObject.someProperty", the compiler would
>> output:
>> >>>
>> >>>   "myModel" + "." + "subObject" + "." + "someProperty"
>> >>>
>> >>> I've also seen information that indicates we might be able to control
>> >>>or
>> >>> provide hints to GCC about what it can rename such that a smarter
>> >>>FalconJX
>> >>> could look for dynamic access and tell GCC not to rename properties in
>> >>> classes it knows will be dynamically accesses and let GCC rename
>> >>> everything else.
>> >>>
>> >>> Volunteers are welcome to do more research on leveraging and
>> >>>controlling
>> >>> GCC renaming.  I haven't made it a high priority for me.
>> >>>
>> >>> My 2 cents,
>> >>> -Alex
>> >>>
>> >>>
>> >>
>>
>>
>

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove <gr...@gmail.com>]

I hadn't investigated any of this, just wondered about it I will check the
reflection results today.
I had actually assumed that @export and @expose explicitly prevented
renaming, but also had not checked this.



On Thu, Sep 29, 2016 at 7:13 AM, Alex Harui <ah...@adobe.com> wrote:

> In fact, when I last touched it, Reflection was optional.  Unless you
> actually use a reflection API (whose code path access
> FLEXJS_REFLECTION_INFO), GCC did not output FLEXJS_REFLECTION_INFO in the
> minified results.  Probably worth verifying that is still true.
>
> What I don't know is whether dead code is removed before renaming.  I hope
> so (and it makes sense to do it that way), otherwise the strings in
> FLEXJS_REFLECTION_INFO may prevent renaming.
>
> All that is part of Pay-as-you-go.  A related goal is to make the "opt-in"
> automatic.  IOW, we don't want folks to have to set compiler options to
> get features. They should come in as you use the APIs.
>
> -Alex
>
> On 9/28/16, 11:05 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
> > "reflection support could be opt-in (or opt-out)"
> >
> >On reflection (pun unintended) maybe that is not sensible, given it is
> >baked in to the framework classes. If GCC does dead-code elimination,
> >maybe
> >that does the job anyhow.
> >
> >
> >
> >On Thu, Sep 29, 2016 at 7:02 AM, Greg Dove <gr...@gmail.com> wrote:
> >
> >> Alex, I had also considered the same idea of doing the qualifiedName
> >> splitting in the reflection data because I think you would reduce a lot
> >>of
> >> long string variation in the GCC release build simply by doing
> >> 'org.apache.flex.'+'Package.'+'ClassName' etc
> >>
> >> Isn't using the reflection member definition names for access also
> >>another
> >> use that would qualify as 'dynamic' access? I am not sure if GCC can
> >>make
> >> the connection between the reflection data field names and the original
> >> naming of the fields which is why we need @export on instance members
> >>and
> >> @expose on static members (without those it fails iirc).
> >>
> >> One option for the future might be to make Reflection support optional.
> >>I
> >> think we might still want FLEXJS_CLASS_INFO, but perhaps the rest of the
> >> the reflection support could be opt-in (or opt-out). This alone could
> >> reduce a lot of code for people who don't need that.
> >>
> >>
> >>
> >>
> >> On Thu, Sep 29, 2016 at 6:17 AM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >>>
> >>>
> >>> On 9/28/16, 3:25 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>
> >>> >I like this idea and would propose taking it one step further:
> >>> >
> >>> >Currently transpiled javascript has fully qualified class names for
> >>> >pretty much everything. This is difficult for closure to minimize
> >>> >completely. I’d really like to have some way to “export” class names
> >>>as
> >>> >well as “import” to define some compact name for packages. Based on my
> >>> >playing around, this could save at least tens of KB of JS downloads.
> >>>
> >>> For sure, the amount of download for strings is a significant waste of
> >>> bytes in most cases.  However, I'm not sure we need to provide renaming
> >>> controls for folks building FlexJS apps, at least not for the
> >>>mainstream.
> >>>
> >>> AIUI, every public property and method in FlexJS is "exported" to
> >>>prevent
> >>> renaming for a few "just-in-case" reasons.  First, a review of
> >>>renaming:
> >>>
> >>> FlexJS uses the Google Closure Compiler to optimize/minify the output
> >>>JS
> >>> file.  In doing so, GCC tries to renaming variables.  For example,
> >>>every
> >>> FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might
> >>>rename
> >>> that property to just "a", so the original JS might look like:
> >>>
> >>>     UIBase.prototype.FLEXJS_CLASS_INFO = {..};
> >>>
> >>> But GCC will cause that to look like:
> >>>
> >>>     UIBase.prototype.a = {..};
> >>>
> >>> If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you
> >>>can
> >>> save quite a bit of download size.  But then, what happens if someone
> >>> writes code that looks like:
> >>>
> >>>     var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
> >>>     var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];
> >>>
> >>> For the first line, GCC will know to alter the code to look like:
> >>>
> >>>     var foo:Object = someUIBase.a;
> >>>
> >>> And everything will work fine, but AIUI, GCC does not try to alter
> >>>strings
> >>> so it will not touch the "bar" code and that would fail at runtime
> >>>since
> >>> there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.
> >>>
> >>>
> >>> But I think that GCC is now smart enough that if you actually have a
> >>>line
> >>> like the "bar" line, that will prevent GCC from renaming
> >>> FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that
> >>>the
> >>> output must have the bytes for "FLEXJS_CLASS_INFO" once in order to
> >>>honor
> >>> the string literal, so it will create an alias like aa =
> >>> "FLEXJS_CLASS_INFO" and then the code is output as:
> >>>
> >>>     UIBase.prototype[aa] = {..};
> >>> And
> >>>     var foo:Object = someUIBase[aa];
> >>>     var bar:Object = someUIBase[aa];
> >>>
> >>> IOW, GCC has a pretty good alias generator, which is why I don't think
> >>>our
> >>> tool chain needs to provide folks with the manual options to rename.
> >>>We
> >>> should just let GCC do its thing.
> >>>
> >>>
> >>> So, AIUI, the reason we export every public thing isn't for the
> >>>standard
> >>> dynamic access case as shown above, but for two others (and related
> >>> scenarios):
> >>> -Dynamic access using generated strings
> >>> -Binding expressions with "dot-paths"
> >>>
> >>> Dynamic access using generated strings are scenarios where you know
> >>>that
> >>> every property starts with "str_" and run code like:
> >>>
> >>>    var foo:String = bar["str_" + i];
> >>>
> >>> GCC isn't smart enough to handle this.
> >>>
> >>> Dot-path Binding Expressions are where you want to use data binding to
> >>> bind to "myModel.subObject.someProperty".  GCC will just look at the
> >>> entire string and since it doesn't match any property it will rename
> >>> myModel and subObject and someProperty and the binding will fail at
> >>> runtime.
> >>>
> >>> So, AIUI, we have huge string tables in our apps for these two cases
> >>>even
> >>> though 99% or even 100% of the time, your app isn't going to access
> >>>those
> >>> methods and properties in a way that GCC can't detect.  So, before we
> >>>add
> >>> some user-controlled renaming, I think we should first explore a
> >>>compiler
> >>> option like -no-rename where you guarantee that your app doesn't use
> >>> generated strings or dot-path binding expressions and we clear all the
> >>> @exports out of the code before sending it to GCC.
> >>>
> >>> I'll bet somewhere in the framework we do use generated strings and
> >>>will
> >>> have to fix that up, but I think that should be doable.  I think the
> >>> compiler could also output string literals with "." in them as separate
> >>> strings and that might solve the dot-path problem.  IOW, instead of
> >>>simply
> >>> outputting "myModel.subObject.someProperty", the compiler would
> output:
> >>>
> >>>   "myModel" + "." + "subObject" + "." + "someProperty"
> >>>
> >>> I've also seen information that indicates we might be able to control
> >>>or
> >>> provide hints to GCC about what it can rename such that a smarter
> >>>FalconJX
> >>> could look for dynamic access and tell GCC not to rename properties in
> >>> classes it knows will be dynamically accesses and let GCC rename
> >>> everything else.
> >>>
> >>> Volunteers are welcome to do more research on leveraging and
> >>>controlling
> >>> GCC renaming.  I haven't made it a high priority for me.
> >>>
> >>> My 2 cents,
> >>> -Alex
> >>>
> >>>
> >>
>
>

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Alex Harui <ah...@adobe.com>]

In fact, when I last touched it, Reflection was optional.  Unless you
actually use a reflection API (whose code path access
FLEXJS_REFLECTION_INFO), GCC did not output FLEXJS_REFLECTION_INFO in the
minified results.  Probably worth verifying that is still true.

What I don't know is whether dead code is removed before renaming.  I hope
so (and it makes sense to do it that way), otherwise the strings in
FLEXJS_REFLECTION_INFO may prevent renaming.

All that is part of Pay-as-you-go.  A related goal is to make the "opt-in"
automatic.  IOW, we don't want folks to have to set compiler options to
get features. They should come in as you use the APIs.

-Alex

On 9/28/16, 11:05 AM, "Greg Dove" <gr...@gmail.com> wrote:

> "reflection support could be opt-in (or opt-out)"
>
>On reflection (pun unintended) maybe that is not sensible, given it is
>baked in to the framework classes. If GCC does dead-code elimination,
>maybe
>that does the job anyhow.
>
>
>
>On Thu, Sep 29, 2016 at 7:02 AM, Greg Dove <gr...@gmail.com> wrote:
>
>> Alex, I had also considered the same idea of doing the qualifiedName
>> splitting in the reflection data because I think you would reduce a lot
>>of
>> long string variation in the GCC release build simply by doing
>> 'org.apache.flex.'+'Package.'+'ClassName' etc
>>
>> Isn't using the reflection member definition names for access also
>>another
>> use that would qualify as 'dynamic' access? I am not sure if GCC can
>>make
>> the connection between the reflection data field names and the original
>> naming of the fields which is why we need @export on instance members
>>and
>> @expose on static members (without those it fails iirc).
>>
>> One option for the future might be to make Reflection support optional.
>>I
>> think we might still want FLEXJS_CLASS_INFO, but perhaps the rest of the
>> the reflection support could be opt-in (or opt-out). This alone could
>> reduce a lot of code for people who don't need that.
>>
>>
>>
>>
>> On Thu, Sep 29, 2016 at 6:17 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>>>
>>>
>>> On 9/28/16, 3:25 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> >I like this idea and would propose taking it one step further:
>>> >
>>> >Currently transpiled javascript has fully qualified class names for
>>> >pretty much everything. This is difficult for closure to minimize
>>> >completely. I’d really like to have some way to “export” class names
>>>as
>>> >well as “import” to define some compact name for packages. Based on my
>>> >playing around, this could save at least tens of KB of JS downloads.
>>>
>>> For sure, the amount of download for strings is a significant waste of
>>> bytes in most cases.  However, I'm not sure we need to provide renaming
>>> controls for folks building FlexJS apps, at least not for the
>>>mainstream.
>>>
>>> AIUI, every public property and method in FlexJS is "exported" to
>>>prevent
>>> renaming for a few "just-in-case" reasons.  First, a review of
>>>renaming:
>>>
>>> FlexJS uses the Google Closure Compiler to optimize/minify the output
>>>JS
>>> file.  In doing so, GCC tries to renaming variables.  For example,
>>>every
>>> FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might
>>>rename
>>> that property to just "a", so the original JS might look like:
>>>
>>>     UIBase.prototype.FLEXJS_CLASS_INFO = {..};
>>>
>>> But GCC will cause that to look like:
>>>
>>>     UIBase.prototype.a = {..};
>>>
>>> If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you
>>>can
>>> save quite a bit of download size.  But then, what happens if someone
>>> writes code that looks like:
>>>
>>>     var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
>>>     var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];
>>>
>>> For the first line, GCC will know to alter the code to look like:
>>>
>>>     var foo:Object = someUIBase.a;
>>>
>>> And everything will work fine, but AIUI, GCC does not try to alter
>>>strings
>>> so it will not touch the "bar" code and that would fail at runtime
>>>since
>>> there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.
>>>
>>>
>>> But I think that GCC is now smart enough that if you actually have a
>>>line
>>> like the "bar" line, that will prevent GCC from renaming
>>> FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that
>>>the
>>> output must have the bytes for "FLEXJS_CLASS_INFO" once in order to
>>>honor
>>> the string literal, so it will create an alias like aa =
>>> "FLEXJS_CLASS_INFO" and then the code is output as:
>>>
>>>     UIBase.prototype[aa] = {..};
>>> And
>>>     var foo:Object = someUIBase[aa];
>>>     var bar:Object = someUIBase[aa];
>>>
>>> IOW, GCC has a pretty good alias generator, which is why I don't think
>>>our
>>> tool chain needs to provide folks with the manual options to rename.
>>>We
>>> should just let GCC do its thing.
>>>
>>>
>>> So, AIUI, the reason we export every public thing isn't for the
>>>standard
>>> dynamic access case as shown above, but for two others (and related
>>> scenarios):
>>> -Dynamic access using generated strings
>>> -Binding expressions with "dot-paths"
>>>
>>> Dynamic access using generated strings are scenarios where you know
>>>that
>>> every property starts with "str_" and run code like:
>>>
>>>    var foo:String = bar["str_" + i];
>>>
>>> GCC isn't smart enough to handle this.
>>>
>>> Dot-path Binding Expressions are where you want to use data binding to
>>> bind to "myModel.subObject.someProperty".  GCC will just look at the
>>> entire string and since it doesn't match any property it will rename
>>> myModel and subObject and someProperty and the binding will fail at
>>> runtime.
>>>
>>> So, AIUI, we have huge string tables in our apps for these two cases
>>>even
>>> though 99% or even 100% of the time, your app isn't going to access
>>>those
>>> methods and properties in a way that GCC can't detect.  So, before we
>>>add
>>> some user-controlled renaming, I think we should first explore a
>>>compiler
>>> option like -no-rename where you guarantee that your app doesn't use
>>> generated strings or dot-path binding expressions and we clear all the
>>> @exports out of the code before sending it to GCC.
>>>
>>> I'll bet somewhere in the framework we do use generated strings and
>>>will
>>> have to fix that up, but I think that should be doable.  I think the
>>> compiler could also output string literals with "." in them as separate
>>> strings and that might solve the dot-path problem.  IOW, instead of
>>>simply
>>> outputting "myModel.subObject.someProperty", the compiler would output:
>>>
>>>   "myModel" + "." + "subObject" + "." + "someProperty"
>>>
>>> I've also seen information that indicates we might be able to control
>>>or
>>> provide hints to GCC about what it can rename such that a smarter
>>>FalconJX
>>> could look for dynamic access and tell GCC not to rename properties in
>>> classes it knows will be dynamically accesses and let GCC rename
>>> everything else.
>>>
>>> Volunteers are welcome to do more research on leveraging and
>>>controlling
>>> GCC renaming.  I haven't made it a high priority for me.
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>>
>>

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove <gr...@gmail.com>]

 "reflection support could be opt-in (or opt-out)"

On reflection (pun unintended) maybe that is not sensible, given it is
baked in to the framework classes. If GCC does dead-code elimination, maybe
that does the job anyhow.



On Thu, Sep 29, 2016 at 7:02 AM, Greg Dove <gr...@gmail.com> wrote:

> Alex, I had also considered the same idea of doing the qualifiedName
> splitting in the reflection data because I think you would reduce a lot of
> long string variation in the GCC release build simply by doing
> 'org.apache.flex.'+'Package.'+'ClassName' etc
>
> Isn't using the reflection member definition names for access also another
> use that would qualify as 'dynamic' access? I am not sure if GCC can make
> the connection between the reflection data field names and the original
> naming of the fields which is why we need @export on instance members and
> @expose on static members (without those it fails iirc).
>
> One option for the future might be to make Reflection support optional. I
> think we might still want FLEXJS_CLASS_INFO, but perhaps the rest of the
> the reflection support could be opt-in (or opt-out). This alone could
> reduce a lot of code for people who don't need that.
>
>
>
>
> On Thu, Sep 29, 2016 at 6:17 AM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 9/28/16, 3:25 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> >I like this idea and would propose taking it one step further:
>> >
>> >Currently transpiled javascript has fully qualified class names for
>> >pretty much everything. This is difficult for closure to minimize
>> >completely. I’d really like to have some way to “export” class names as
>> >well as “import” to define some compact name for packages. Based on my
>> >playing around, this could save at least tens of KB of JS downloads.
>>
>> For sure, the amount of download for strings is a significant waste of
>> bytes in most cases.  However, I'm not sure we need to provide renaming
>> controls for folks building FlexJS apps, at least not for the mainstream.
>>
>> AIUI, every public property and method in FlexJS is "exported" to prevent
>> renaming for a few "just-in-case" reasons.  First, a review of renaming:
>>
>> FlexJS uses the Google Closure Compiler to optimize/minify the output JS
>> file.  In doing so, GCC tries to renaming variables.  For example, every
>> FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might rename
>> that property to just "a", so the original JS might look like:
>>
>>     UIBase.prototype.FLEXJS_CLASS_INFO = {..};
>>
>> But GCC will cause that to look like:
>>
>>     UIBase.prototype.a = {..};
>>
>> If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you can
>> save quite a bit of download size.  But then, what happens if someone
>> writes code that looks like:
>>
>>     var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
>>     var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];
>>
>> For the first line, GCC will know to alter the code to look like:
>>
>>     var foo:Object = someUIBase.a;
>>
>> And everything will work fine, but AIUI, GCC does not try to alter strings
>> so it will not touch the "bar" code and that would fail at runtime since
>> there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.
>>
>>
>> But I think that GCC is now smart enough that if you actually have a line
>> like the "bar" line, that will prevent GCC from renaming
>> FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that the
>> output must have the bytes for "FLEXJS_CLASS_INFO" once in order to honor
>> the string literal, so it will create an alias like aa =
>> "FLEXJS_CLASS_INFO" and then the code is output as:
>>
>>     UIBase.prototype[aa] = {..};
>> And
>>     var foo:Object = someUIBase[aa];
>>     var bar:Object = someUIBase[aa];
>>
>> IOW, GCC has a pretty good alias generator, which is why I don't think our
>> tool chain needs to provide folks with the manual options to rename.  We
>> should just let GCC do its thing.
>>
>>
>> So, AIUI, the reason we export every public thing isn't for the standard
>> dynamic access case as shown above, but for two others (and related
>> scenarios):
>> -Dynamic access using generated strings
>> -Binding expressions with "dot-paths"
>>
>> Dynamic access using generated strings are scenarios where you know that
>> every property starts with "str_" and run code like:
>>
>>    var foo:String = bar["str_" + i];
>>
>> GCC isn't smart enough to handle this.
>>
>> Dot-path Binding Expressions are where you want to use data binding to
>> bind to "myModel.subObject.someProperty".  GCC will just look at the
>> entire string and since it doesn't match any property it will rename
>> myModel and subObject and someProperty and the binding will fail at
>> runtime.
>>
>> So, AIUI, we have huge string tables in our apps for these two cases even
>> though 99% or even 100% of the time, your app isn't going to access those
>> methods and properties in a way that GCC can't detect.  So, before we add
>> some user-controlled renaming, I think we should first explore a compiler
>> option like -no-rename where you guarantee that your app doesn't use
>> generated strings or dot-path binding expressions and we clear all the
>> @exports out of the code before sending it to GCC.
>>
>> I'll bet somewhere in the framework we do use generated strings and will
>> have to fix that up, but I think that should be doable.  I think the
>> compiler could also output string literals with "." in them as separate
>> strings and that might solve the dot-path problem.  IOW, instead of simply
>> outputting "myModel.subObject.someProperty", the compiler would output:
>>
>>   "myModel" + "." + "subObject" + "." + "someProperty"
>>
>> I've also seen information that indicates we might be able to control or
>> provide hints to GCC about what it can rename such that a smarter FalconJX
>> could look for dynamic access and tell GCC not to rename properties in
>> classes it knows will be dynamically accesses and let GCC rename
>> everything else.
>>
>> Volunteers are welcome to do more research on leveraging and controlling
>> GCC renaming.  I haven't made it a high priority for me.
>>
>> My 2 cents,
>> -Alex
>>
>>
>

Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)

[Greg Dove <gr...@gmail.com>]

Alex, I had also considered the same idea of doing the qualifiedName
splitting in the reflection data because I think you would reduce a lot of
long string variation in the GCC release build simply by doing
'org.apache.flex.'+'Package.'+'ClassName' etc

Isn't using the reflection member definition names for access also another
use that would qualify as 'dynamic' access? I am not sure if GCC can make
the connection between the reflection data field names and the original
naming of the fields which is why we need @export on instance members and
@expose on static members (without those it fails iirc).

One option for the future might be to make Reflection support optional. I
think we might still want FLEXJS_CLASS_INFO, but perhaps the rest of the
the reflection support could be opt-in (or opt-out). This alone could
reduce a lot of code for people who don't need that.




On Thu, Sep 29, 2016 at 6:17 AM, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 9/28/16, 3:25 AM, "Harbs" <ha...@gmail.com> wrote:
>
> >I like this idea and would propose taking it one step further:
> >
> >Currently transpiled javascript has fully qualified class names for
> >pretty much everything. This is difficult for closure to minimize
> >completely. I’d really like to have some way to “export” class names as
> >well as “import” to define some compact name for packages. Based on my
> >playing around, this could save at least tens of KB of JS downloads.
>
> For sure, the amount of download for strings is a significant waste of
> bytes in most cases.  However, I'm not sure we need to provide renaming
> controls for folks building FlexJS apps, at least not for the mainstream.
>
> AIUI, every public property and method in FlexJS is "exported" to prevent
> renaming for a few "just-in-case" reasons.  First, a review of renaming:
>
> FlexJS uses the Google Closure Compiler to optimize/minify the output JS
> file.  In doing so, GCC tries to renaming variables.  For example, every
> FlexJS class has a FLEXJS_CLASS_INFO property on it.  Google might rename
> that property to just "a", so the original JS might look like:
>
>     UIBase.prototype.FLEXJS_CLASS_INFO = {..};
>
> But GCC will cause that to look like:
>
>     UIBase.prototype.a = {..};
>
> If you replace "FLEXJS_CLASS_INFO" with "a" in every FlexJS class, you can
> save quite a bit of download size.  But then, what happens if someone
> writes code that looks like:
>
>     var foo:Object = someUIBase.FLEXJS_CLASS_INFO;
>     var bar:Object = someUIBase["FLEXJS_CLASS_INFO"];
>
> For the first line, GCC will know to alter the code to look like:
>
>     var foo:Object = someUIBase.a;
>
> And everything will work fine, but AIUI, GCC does not try to alter strings
> so it will not touch the "bar" code and that would fail at runtime since
> there is no longer a property called "FLEXJS_CLASS_INFO" on UIBase.
>
>
> But I think that GCC is now smart enough that if you actually have a line
> like the "bar" line, that will prevent GCC from renaming
> FLEXJS_CLASS_INFO.  GCC might make an alias instead.  GCC knows that the
> output must have the bytes for "FLEXJS_CLASS_INFO" once in order to honor
> the string literal, so it will create an alias like aa =
> "FLEXJS_CLASS_INFO" and then the code is output as:
>
>     UIBase.prototype[aa] = {..};
> And
>     var foo:Object = someUIBase[aa];
>     var bar:Object = someUIBase[aa];
>
> IOW, GCC has a pretty good alias generator, which is why I don't think our
> tool chain needs to provide folks with the manual options to rename.  We
> should just let GCC do its thing.
>
>
> So, AIUI, the reason we export every public thing isn't for the standard
> dynamic access case as shown above, but for two others (and related
> scenarios):
> -Dynamic access using generated strings
> -Binding expressions with "dot-paths"
>
> Dynamic access using generated strings are scenarios where you know that
> every property starts with "str_" and run code like:
>
>    var foo:String = bar["str_" + i];
>
> GCC isn't smart enough to handle this.
>
> Dot-path Binding Expressions are where you want to use data binding to
> bind to "myModel.subObject.someProperty".  GCC will just look at the
> entire string and since it doesn't match any property it will rename
> myModel and subObject and someProperty and the binding will fail at
> runtime.
>
> So, AIUI, we have huge string tables in our apps for these two cases even
> though 99% or even 100% of the time, your app isn't going to access those
> methods and properties in a way that GCC can't detect.  So, before we add
> some user-controlled renaming, I think we should first explore a compiler
> option like -no-rename where you guarantee that your app doesn't use
> generated strings or dot-path binding expressions and we clear all the
> @exports out of the code before sending it to GCC.
>
> I'll bet somewhere in the framework we do use generated strings and will
> have to fix that up, but I think that should be doable.  I think the
> compiler could also output string literals with "." in them as separate
> strings and that might solve the dot-path problem.  IOW, instead of simply
> outputting "myModel.subObject.someProperty", the compiler would output:
>
>   "myModel" + "." + "subObject" + "." + "someProperty"
>
> I've also seen information that indicates we might be able to control or
> provide hints to GCC about what it can rename such that a smarter FalconJX
> could look for dynamic access and tell GCC not to rename properties in
> classes it knows will be dynamically accesses and let GCC rename
> everything else.
>
> Volunteers are welcome to do more research on leveraging and controlling
> GCC renaming.  I haven't made it a high priority for me.
>
> My 2 cents,
> -Alex
>
>