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 <greg.d...@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 <aha...@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" <greg.d...@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 <greg.d...@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 <aha...@adobe.com> wrote:
>> >>
>> >>>
>> >>>
>> >>> On 9/28/16, 3:25 AM, "Harbs" <harbs.li...@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
>> >>>
>> >>>
>> >>
>>
>>
>
