Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

piotrz
Hi Yishay,

I think you could use constant here -> HTTPConstants.POST

Thanks, Piotr

2017-07-11 10:09 GMT+02:00 <[hidden email]>:

> Repository: flex-asjs
> Updated Branches:
>   refs/heads/develop cc098932c -> 3b5053f91
>
>
> Uploads are assumed to be POST
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/3b5053f9
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/3b5053f9
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/3b5053f9
>
> Branch: refs/heads/develop
> Commit: 3b5053f91f869a7fd4cd1eccf80e696e5171b532
> Parents: cc09893
> Author: DESKTOP-RH4S838\Yishay <[hidden email]>
> Authored: Tue Jul 11 11:08:32 2017 +0300
> Committer: DESKTOP-RH4S838\Yishay <[hidden email]>
> Committed: Tue Jul 11 11:08:32 2017 +0300
>
> ----------------------------------------------------------------------
>  .../src/main/flex/org/apache/flex/file/beads/FileUploader.as        | 1 +
>  1 file changed, 1 insertion(+)
> ----------------------------------------------------------------------
>
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 3b5053f9/frameworks/projects/Network/src/main/flex/org/
> apache/flex/file/beads/FileUploader.as
> ----------------------------------------------------------------------
> diff --git a/frameworks/projects/Network/src/main/flex/org/apache/flex/file/beads/FileUploader.as
> b/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> index e9aad3c..194a1d6 100644
> --- a/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> +++ b/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> @@ -80,6 +80,7 @@ package org.apache.flex.file.beads
>  //                     }
>                         var binaryUploader:URLBinaryLoader = new
> URLBinaryLoader();
>                         var req:URLRequest = new URLRequest();
> +                       req.method = "POST";
>                         req.data = (host.model as FileModel).blob;
>                         req.url = url;
>                         binaryUploader.addEventListener(Event.COMPLETE,
> completeHandler);
>
>
Reply | Threaded
Open this post in threaded view
|

RE: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

yishayw
I was trying to save an extra import. Will wait for more thoughts on this.

From: Piotr Zarzycki<mailto:[hidden email]>
Sent: Tuesday, July 11, 2017 11:15 AM
To: [hidden email]<mailto:[hidden email]>
Subject: Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Hi Yishay,

I think you could use constant here -> HTTPConstants.POST

Thanks, Piotr

2017-07-11 10:09 GMT+02:00 <[hidden email]>:

> Repository: flex-asjs
> Updated Branches:
>   refs/heads/develop cc098932c -> 3b5053f91
>
>
> Uploads are assumed to be POST
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/3b5053f9
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/3b5053f9
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/3b5053f9
>
> Branch: refs/heads/develop
> Commit: 3b5053f91f869a7fd4cd1eccf80e696e5171b532
> Parents: cc09893
> Author: DESKTOP-RH4S838\Yishay <[hidden email]>
> Authored: Tue Jul 11 11:08:32 2017 +0300
> Committer: DESKTOP-RH4S838\Yishay <[hidden email]>
> Committed: Tue Jul 11 11:08:32 2017 +0300
>
> ----------------------------------------------------------------------
>  .../src/main/flex/org/apache/flex/file/beads/FileUploader.as        | 1 +
>  1 file changed, 1 insertion(+)
> ----------------------------------------------------------------------
>
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 3b5053f9/frameworks/projects/Network/src/main/flex/org/
> apache/flex/file/beads/FileUploader.as
> ----------------------------------------------------------------------
> diff --git a/frameworks/projects/Network/src/main/flex/org/apache/flex/file/beads/FileUploader.as
> b/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> index e9aad3c..194a1d6 100644
> --- a/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> +++ b/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> @@ -80,6 +80,7 @@ package org.apache.flex.file.beads
>  //                     }
>                         var binaryUploader:URLBinaryLoader = new
> URLBinaryLoader();
>                         var req:URLRequest = new URLRequest();
> +                       req.method = "POST";
>                         req.data = (host.model as FileModel).blob;
>                         req.url = url;
>                         binaryUploader.addEventListener(Event.COMPLETE,
> completeHandler);
>
>

Reply | Threaded
Open this post in threaded view
|

RE: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

piotrz
I just think that we should use const whenever we can, but won't fight for that if no one think similar. :) If I found such code around my interest my natural move would be change it :)

Piotr
Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Harbs
This is worthy of a discussion.

As it stands now, use of constants result in more JS code after compiled. It’s possible that this can be optimized, but currently the most efficient JS code is produced if using string literals rather than constants. (The Google compiler created variables for string literals used more than once.)

My preference would be to try to stick to string literals in Framework code. This has two advantages:
1. There’s no calls to constants in the compiled code so we save bytes.
2. The constant classes are not required, so they are not included in the compiled code unless client code uses them.

As long as we’re careful to use the correct strings, this should not be an issue. If the strings are complex and/or subject to change, then they should be declared once and constants should be used. Otherwise, I think the advantages of using string literals outweigh the “correctness” of using constants.

Thanks,
Harbs

> On Jul 11, 2017, at 11:46 AM, piotrz <[hidden email]> wrote:
>
> I just think that we should use const whenever we can, but won't fight for
> that if no one think similar. :) If I found such code around my interest my
> natural move would be change it :)
>
> Piotr
>
>
>
> -----
> Apache Flex PMC
> [hidden email]
> --
> View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-Uploads-are-assumed-to-be-POST-tp63070p63078.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

RE: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

yishayw
In reply to this post by piotrz
Normally I would agree, but I was trying to be strict about PAYG in these commits. Let’s see what the others say.

From: piotrz<mailto:[hidden email]>
Sent: Tuesday, July 11, 2017 12:05 PM
To: [hidden email]<mailto:[hidden email]>
Subject: RE: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

I just think that we should use const whenever we can, but won't fight for
that if no one think similar. :) If I found such code around my interest my
natural move would be change it :)

Piotr



-----
Apache Flex PMC
[hidden email]
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-Uploads-are-assumed-to-be-POST-tp63070p63078.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

piotrz
In reply to this post by Harbs
Thanks for explanation. I will try to be careful in usage. I think this natural move to use constant is more from AS3 world than JS :)

Piotr
Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Justin Mclean
Administrator
In reply to this post by Harbs
Hi,

> As it stands now, use of constants result in more JS code after compiled.

Debug yes but not optimised / release.

> It’s possible that this can be optimized, but currently the most efficient JS code is produced if using string literals rather than constants. (The Google compiler created variables for string literals used more than once.)

That's not we found in a previous thread on this list, the google compiler optimises the constants and there is no penalty in using them. You mind provide examples that show the above is the actually case and document it on the wiki?

My vote would be not the duplicate the strings everywhere and use constants as there is no cost and increased safety.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Harbs
Here’s what is output in the minimized code:

function fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');w('org.apache.flex.net.HTTPConstants.POST','POST');w('org.apache.flex.net.HTTPConstants.PUT','PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_ENCODED',Fm);w('org.apache.flex.net.HTTPConstants.DELETE','DELETE');w('org.apache.flex.net.HTTPConstants.OPEN','open');w('org.apache.flex.net.HTTPConstants.COMPLETE',Bt);w('org.apache.flex.net.HTTPConstants.COMMUNICATION_ERROR',At);w('org.apache.flex.net.HTTPConstants.IO_ERROR','ioError');
w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR','securityError');w('org.apache.flex.net.HTTPConstants.STATUS',Fx);w('org.apache.flex.net.HTTPConstants.RESPONSE_STATUS','httpResponseStatus');fqa.prototype.h={names:[{name:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);

elsewhere:
IF='org.apache.flex.net.HTTPConstants’,

That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…

No idea what wiki you are referring to.

Harbs

> On Jul 11, 2017, at 2:36 PM, Justin Mclean <[hidden email]> wrote:
>
> Hi,
>
>> As it stands now, use of constants result in more JS code after compiled.
>
> Debug yes but not optimised / release.
>
>> It’s possible that this can be optimized, but currently the most efficient JS code is produced if using string literals rather than constants. (The Google compiler created variables for string literals used more than once.)
>
> That's not we found in a previous thread on this list, the google compiler optimises the constants and there is no penalty in using them. You mind provide examples that show the above is the actually case and document it on the wiki?
>
> My vote would be not the duplicate the strings everywhere and use constants as there is no cost and increased safety.
>
> Thanks,
> Justin

Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Alex Harui-2
AIUI, there is a cost in the minified JS to using constants.

However, there is a cost to screwing up the typing of a string literal as
well.

The best answer for now, IMO, is to not care whether folks use constants
or string literals.  There are much bigger fish to fry.  I don't want to
see sweeping changes of replacing all string literals with constants or
vice versa.  If you've got that kind of time on your hands, learn the
compiler code and see if you can make the cross-compiler replace all
constants with string literals.  IMO, that's the right answer.

-Alex

On 7/11/17, 5:37 AM, "Harbs" <[hidden email]> wrote:

>Here’s what is output in the minimized code:
>
>function
>fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');w('org.apache.flex
>.net.HTTPConstants.POST','POST');w('org.apache.flex.net.HTTPConstants.PUT'
>,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_ENCODED',Fm);w('org.
>apache.flex.net.HTTPConstants.DELETE','DELETE');w('org.apache.flex.net.HTT
>PConstants.OPEN','open');w('org.apache.flex.net.HTTPConstants.COMPLETE',Bt
>);w('org.apache.flex.net.HTTPConstants.COMMUNICATION_ERROR',At);w('org.apa
>che.flex.net.HTTPConstants.IO_ERROR','ioError');
>w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR','securityError');w('o
>rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('org.apache.flex.net.HTTPCo
>nstants.RESPONSE_STATUS','httpResponseStatus');fqa.prototype.h={names:[{na
>me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
>
>elsewhere:
>IF='org.apache.flex.net.HTTPConstants’,
>
>That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
>
>No idea what wiki you are referring to.
>
>Harbs
>
>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <[hidden email]>
>>wrote:
>>
>> Hi,
>>
>>> As it stands now, use of constants result in more JS code after
>>>compiled.
>>
>> Debug yes but not optimised / release.
>>
>>> It’s possible that this can be optimized, but currently the most
>>>efficient JS code is produced if using string literals rather than
>>>constants. (The Google compiler created variables for string literals
>>>used more than once.)
>>
>> That's not we found in a previous thread on this list, the google
>>compiler optimises the constants and there is no penalty in using them.
>>You mind provide examples that show the above is the actually case and
>>document it on the wiki?
>>
>> My vote would be not the duplicate the strings everywhere and use
>>constants as there is no cost and increased safety.
>>
>> Thanks,
>> Justin
>

Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Josh Tynjala
That sounds like the proper way to handle this! We should be able to
reference constants in our ActionScript so that we can get compile-time
errors from typos, while the compiler makes sure that generated JavaScript
can be properly minified.

- Josh

On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <[hidden email]>
wrote:

> AIUI, there is a cost in the minified JS to using constants.
>
> However, there is a cost to screwing up the typing of a string literal as
> well.
>
> The best answer for now, IMO, is to not care whether folks use constants
> or string literals.  There are much bigger fish to fry.  I don't want to
> see sweeping changes of replacing all string literals with constants or
> vice versa.  If you've got that kind of time on your hands, learn the
> compiler code and see if you can make the cross-compiler replace all
> constants with string literals.  IMO, that's the right answer.
>
> -Alex
>
> On 7/11/17, 5:37 AM, "Harbs" <[hidden email]> wrote:
>
> >Here’s what is output in the minimized code:
> >
> >function
> >fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
> w('org.apache.flex
> >.net.HTTPConstants.POST','POST');w('org.apache.flex.net.
> HTTPConstants.PUT'
> >,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
> ENCODED',Fm);w('org.
> >apache.flex.net.HTTPConstants.DELETE','DELETE'
> );w('org.apache.flex.net.HTT
> >PConstants.OPEN','open');w('org.apache.flex.net.
> HTTPConstants.COMPLETE',Bt
> >);w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
> ERROR',At);w('org.apa
> >che.flex.net.HTTPConstants.IO_ERROR','ioError');
> >w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
> 'securityError');w('o
> >rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
> org.apache.flex.net.HTTPCo
> >nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
> prototype.h={names:[{na
> >me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
> >
> >elsewhere:
> >IF='org.apache.flex.net.HTTPConstants’,
> >
> >That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
> >
> >No idea what wiki you are referring to.
> >
> >Harbs
> >
> >> On Jul 11, 2017, at 2:36 PM, Justin Mclean <[hidden email]>
> >>wrote:
> >>
> >> Hi,
> >>
> >>> As it stands now, use of constants result in more JS code after
> >>>compiled.
> >>
> >> Debug yes but not optimised / release.
> >>
> >>> It’s possible that this can be optimized, but currently the most
> >>>efficient JS code is produced if using string literals rather than
> >>>constants. (The Google compiler created variables for string literals
> >>>used more than once.)
> >>
> >> That's not we found in a previous thread on this list, the google
> >>compiler optimises the constants and there is no penalty in using them.
> >>You mind provide examples that show the above is the actually case and
> >>document it on the wiki?
> >>
> >> My vote would be not the duplicate the strings everywhere and use
> >>constants as there is no cost and increased safety.
> >>
> >> Thanks,
> >> Justin
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Harbs
+1.

I also think that we have bigger fish to fry first.

My point was not to force one way or the other. Rather that the way it currently stands there’s a valid reason to use string literals. I was not suggesting changing anything.

Thanks,
Harbs

> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <[hidden email]> wrote:
>
> That sounds like the proper way to handle this! We should be able to
> reference constants in our ActionScript so that we can get compile-time
> errors from typos, while the compiler makes sure that generated JavaScript
> can be properly minified.
>
> - Josh
>
> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <[hidden email]>
> wrote:
>
>> AIUI, there is a cost in the minified JS to using constants.
>>
>> However, there is a cost to screwing up the typing of a string literal as
>> well.
>>
>> The best answer for now, IMO, is to not care whether folks use constants
>> or string literals.  There are much bigger fish to fry.  I don't want to
>> see sweeping changes of replacing all string literals with constants or
>> vice versa.  If you've got that kind of time on your hands, learn the
>> compiler code and see if you can make the cross-compiler replace all
>> constants with string literals.  IMO, that's the right answer.
>>
>> -Alex
>>
>> On 7/11/17, 5:37 AM, "Harbs" <[hidden email]> wrote:
>>
>>> Here’s what is output in the minimized code:
>>>
>>> function
>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
>> w('org.apache.flex
>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
>> HTTPConstants.PUT'
>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
>> ENCODED',Fm);w('org.
>>> apache.flex.net.HTTPConstants.DELETE','DELETE'
>> );w('org.apache.flex.net.HTT
>>> PConstants.OPEN','open');w('org.apache.flex.net.
>> HTTPConstants.COMPLETE',Bt
>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
>> ERROR',At);w('org.apa
>>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
>> 'securityError');w('o
>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
>> org.apache.flex.net.HTTPCo
>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
>> prototype.h={names:[{na
>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
>>>
>>> elsewhere:
>>> IF='org.apache.flex.net.HTTPConstants’,
>>>
>>> That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
>>>
>>> No idea what wiki you are referring to.
>>>
>>> Harbs
>>>
>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <[hidden email]>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>> As it stands now, use of constants result in more JS code after
>>>>> compiled.
>>>>
>>>> Debug yes but not optimised / release.
>>>>
>>>>> It’s possible that this can be optimized, but currently the most
>>>>> efficient JS code is produced if using string literals rather than
>>>>> constants. (The Google compiler created variables for string literals
>>>>> used more than once.)
>>>>
>>>> That's not we found in a previous thread on this list, the google
>>>> compiler optimises the constants and there is no penalty in using them.
>>>> You mind provide examples that show the above is the actually case and
>>>> document it on the wiki?
>>>>
>>>> My vote would be not the duplicate the strings everywhere and use
>>>> constants as there is no cost and increased safety.
>>>>
>>>> Thanks,
>>>> Justin
>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Greg Dove
Guys, we certainly have been here before.

From a js release 'size' perspective, I don't think it matters whether we
use constants or liteterals, I think the main difference is that if the
static const exists it will also be included in the release output as I
expect it has an @export annotation. This means it should be 'reflectable'
via array/bracket access syntax via its original package/class naming. But
in terms of usage sites within the codebase, it should already be optimised
via GCC, becuase GCC is already capable of inlining anything annotated as a
constant [1].
So I would expect it to already be inlined in the js-release, and we
*should not need* to write any code in the jx compiler to do that, unless
we specifically need this inlining (for some reason) in the debug version
of the js output.

GCC also creates a single short named variable to refer to repeated
literals througout the compiled codebase, so I would expect the inlining of
consts would get this as a 2nd optimization pass as well. In the end I
expect the only output difference between the two approaches should be that
we also get an extra exported constant that retains the same naming
convention of lookups etc because we are @export-ing it.

I'm pretty sure this is correct, but I might be wrong. I will check all
this later today, and report back.

1.
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#const-const-type



On Wed, Jul 12, 2017 at 3:47 AM, Harbs <[hidden email]> wrote:

> +1.
>
> I also think that we have bigger fish to fry first.
>
> My point was not to force one way or the other. Rather that the way it
> currently stands there’s a valid reason to use string literals. I was not
> suggesting changing anything.
>
> Thanks,
> Harbs
>
> > On Jul 11, 2017, at 6:33 PM, Josh Tynjala <[hidden email]> wrote:
> >
> > That sounds like the proper way to handle this! We should be able to
> > reference constants in our ActionScript so that we can get compile-time
> > errors from typos, while the compiler makes sure that generated
> JavaScript
> > can be properly minified.
> >
> > - Josh
> >
> > On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <[hidden email]>
> > wrote:
> >
> >> AIUI, there is a cost in the minified JS to using constants.
> >>
> >> However, there is a cost to screwing up the typing of a string literal
> as
> >> well.
> >>
> >> The best answer for now, IMO, is to not care whether folks use constants
> >> or string literals.  There are much bigger fish to fry.  I don't want to
> >> see sweeping changes of replacing all string literals with constants or
> >> vice versa.  If you've got that kind of time on your hands, learn the
> >> compiler code and see if you can make the cross-compiler replace all
> >> constants with string literals.  IMO, that's the right answer.
> >>
> >> -Alex
> >>
> >> On 7/11/17, 5:37 AM, "Harbs" <[hidden email]> wrote:
> >>
> >>> Here’s what is output in the minimized code:
> >>>
> >>> function
> >>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
> >> w('org.apache.flex
> >>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
> >> HTTPConstants.PUT'
> >>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
> >> ENCODED',Fm);w('org.
> >>> apache.flex.net.HTTPConstants.DELETE','DELETE'
> >> );w('org.apache.flex.net.HTT
> >>> PConstants.OPEN','open');w('org.apache.flex.net.
> >> HTTPConstants.COMPLETE',Bt
> >>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
> >> ERROR',At);w('org.apa
> >>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
> >>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
> >> 'securityError');w('o
> >>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
> >> org.apache.flex.net.HTTPCo
> >>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
> >> prototype.h={names:[{na
> >>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
> >>>
> >>> elsewhere:
> >>> IF='org.apache.flex.net.HTTPConstants’,
> >>>
> >>> That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
> >>>
> >>> No idea what wiki you are referring to.
> >>>
> >>> Harbs
> >>>
> >>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <[hidden email]>
> >>>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>> As it stands now, use of constants result in more JS code after
> >>>>> compiled.
> >>>>
> >>>> Debug yes but not optimised / release.
> >>>>
> >>>>> It’s possible that this can be optimized, but currently the most
> >>>>> efficient JS code is produced if using string literals rather than
> >>>>> constants. (The Google compiler created variables for string literals
> >>>>> used more than once.)
> >>>>
> >>>> That's not we found in a previous thread on this list, the google
> >>>> compiler optimises the constants and there is no penalty in using
> them.
> >>>> You mind provide examples that show the above is the actually case and
> >>>> document it on the wiki?
> >>>>
> >>>> My vote would be not the duplicate the strings everywhere and use
> >>>> constants as there is no cost and increased safety.
> >>>>
> >>>> Thanks,
> >>>> Justin
> >>>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Harbs
Hi Greg,

There probably is too much use of @export. @const is probably more correct than @export — as long as we are sure that there’s no use of bracket notation anywhere. I’d be interested in hearing your findings.

Personally, I’m not sure there’s a lot of value to be using @export at all unless an app is using modules of some sort (which I’m not even sure how to do with FlexJS). (but I might be missing something with the @export tag)

What happens if the compiler is run without --generate_exports? Do the @exports get stripped out? If yes, is there some kind of “super export”? There needs to be some way to invoke the app…

Harbs

> On Jul 11, 2017, at 11:40 PM, Greg Dove <[hidden email]> wrote:
>
> Guys, we certainly have been here before.
>
> From a js release 'size' perspective, I don't think it matters whether we
> use constants or liteterals, I think the main difference is that if the
> static const exists it will also be included in the release output as I
> expect it has an @export annotation. This means it should be 'reflectable'
> via array/bracket access syntax via its original package/class naming. But
> in terms of usage sites within the codebase, it should already be optimised
> via GCC, becuase GCC is already capable of inlining anything annotated as a
> constant [1].
> So I would expect it to already be inlined in the js-release, and we
> *should not need* to write any code in the jx compiler to do that, unless
> we specifically need this inlining (for some reason) in the debug version
> of the js output.
>
> GCC also creates a single short named variable to refer to repeated
> literals througout the compiled codebase, so I would expect the inlining of
> consts would get this as a 2nd optimization pass as well. In the end I
> expect the only output difference between the two approaches should be that
> we also get an extra exported constant that retains the same naming
> convention of lookups etc because we are @export-ing it.
>
> I'm pretty sure this is correct, but I might be wrong. I will check all
> this later today, and report back.
>
> 1.
> https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
>
>
>
> On Wed, Jul 12, 2017 at 3:47 AM, Harbs <[hidden email]> wrote:
>
>> +1.
>>
>> I also think that we have bigger fish to fry first.
>>
>> My point was not to force one way or the other. Rather that the way it
>> currently stands there’s a valid reason to use string literals. I was not
>> suggesting changing anything.
>>
>> Thanks,
>> Harbs
>>
>>> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <[hidden email]> wrote:
>>>
>>> That sounds like the proper way to handle this! We should be able to
>>> reference constants in our ActionScript so that we can get compile-time
>>> errors from typos, while the compiler makes sure that generated
>> JavaScript
>>> can be properly minified.
>>>
>>> - Josh
>>>
>>> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <[hidden email]>
>>> wrote:
>>>
>>>> AIUI, there is a cost in the minified JS to using constants.
>>>>
>>>> However, there is a cost to screwing up the typing of a string literal
>> as
>>>> well.
>>>>
>>>> The best answer for now, IMO, is to not care whether folks use constants
>>>> or string literals.  There are much bigger fish to fry.  I don't want to
>>>> see sweeping changes of replacing all string literals with constants or
>>>> vice versa.  If you've got that kind of time on your hands, learn the
>>>> compiler code and see if you can make the cross-compiler replace all
>>>> constants with string literals.  IMO, that's the right answer.
>>>>
>>>> -Alex
>>>>
>>>> On 7/11/17, 5:37 AM, "Harbs" <[hidden email]> wrote:
>>>>
>>>>> Here’s what is output in the minimized code:
>>>>>
>>>>> function
>>>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
>>>> w('org.apache.flex
>>>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
>>>> HTTPConstants.PUT'
>>>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
>>>> ENCODED',Fm);w('org.
>>>>> apache.flex.net.HTTPConstants.DELETE','DELETE'
>>>> );w('org.apache.flex.net.HTT
>>>>> PConstants.OPEN','open');w('org.apache.flex.net.
>>>> HTTPConstants.COMPLETE',Bt
>>>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
>>>> ERROR',At);w('org.apa
>>>>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
>>>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
>>>> 'securityError');w('o
>>>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
>>>> org.apache.flex.net.HTTPCo
>>>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
>>>> prototype.h={names:[{na
>>>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
>>>>>
>>>>> elsewhere:
>>>>> IF='org.apache.flex.net.HTTPConstants’,
>>>>>
>>>>> That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
>>>>>
>>>>> No idea what wiki you are referring to.
>>>>>
>>>>> Harbs
>>>>>
>>>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> As it stands now, use of constants result in more JS code after
>>>>>>> compiled.
>>>>>>
>>>>>> Debug yes but not optimised / release.
>>>>>>
>>>>>>> It’s possible that this can be optimized, but currently the most
>>>>>>> efficient JS code is produced if using string literals rather than
>>>>>>> constants. (The Google compiler created variables for string literals
>>>>>>> used more than once.)
>>>>>>
>>>>>> That's not we found in a previous thread on this list, the google
>>>>>> compiler optimises the constants and there is no penalty in using
>> them.
>>>>>> You mind provide examples that show the above is the actually case and
>>>>>> document it on the wiki?
>>>>>>
>>>>>> My vote would be not the duplicate the strings everywhere and use
>>>>>> constants as there is no cost and increased safety.
>>>>>>
>>>>>> Thanks,
>>>>>> Justin
>>>>>
>>>>
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Greg Dove
I'll try those things, I have not tried any of those options so far.

Future need to support modules has been mentioned as a reason for keeping
@export before.

Another is to support reflection (in its current form). Reflection support
probably needs to be opt-in, I think this has been discussed before also.

Perhaps another in this case might be to support constant bindings.
This is one area that could probably benefit from jx-compiler optimisation
for primitive constant lookups - iirc I *think* that constant bindings are
still happening via bracket access, and probably could simply be replaced
by the literal values for string, number etc.




On Wed, Jul 12, 2017 at 9:57 AM, Harbs <[hidden email]> wrote:

> Hi Greg,
>
> There probably is too much use of @export. @const is probably more correct
> than @export — as long as we are sure that there’s no use of bracket
> notation anywhere. I’d be interested in hearing your findings.
>
> Personally, I’m not sure there’s a lot of value to be using @export at all
> unless an app is using modules of some sort (which I’m not even sure how to
> do with FlexJS). (but I might be missing something with the @export tag)
>
> What happens if the compiler is run without --generate_exports? Do the
> @exports get stripped out? If yes, is there some kind of “super export”?
> There needs to be some way to invoke the app…
>
> Harbs
>
> > On Jul 11, 2017, at 11:40 PM, Greg Dove <[hidden email]> wrote:
> >
> > Guys, we certainly have been here before.
> >
> > From a js release 'size' perspective, I don't think it matters whether we
> > use constants or liteterals, I think the main difference is that if the
> > static const exists it will also be included in the release output as I
> > expect it has an @export annotation. This means it should be
> 'reflectable'
> > via array/bracket access syntax via its original package/class naming.
> But
> > in terms of usage sites within the codebase, it should already be
> optimised
> > via GCC, becuase GCC is already capable of inlining anything annotated
> as a
> > constant [1].
> > So I would expect it to already be inlined in the js-release, and we
> > *should not need* to write any code in the jx compiler to do that, unless
> > we specifically need this inlining (for some reason) in the debug version
> > of the js output.
> >
> > GCC also creates a single short named variable to refer to repeated
> > literals througout the compiled codebase, so I would expect the inlining
> of
> > consts would get this as a 2nd optimization pass as well. In the end I
> > expect the only output difference between the two approaches should be
> that
> > we also get an extra exported constant that retains the same naming
> > convention of lookups etc because we are @export-ing it.
> >
> > I'm pretty sure this is correct, but I might be wrong. I will check all
> > this later today, and report back.
> >
> > 1.
> > https://github.com/google/closure-compiler/wiki/
> Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
> >
> >
> >
> > On Wed, Jul 12, 2017 at 3:47 AM, Harbs <[hidden email]> wrote:
> >
> >> +1.
> >>
> >> I also think that we have bigger fish to fry first.
> >>
> >> My point was not to force one way or the other. Rather that the way it
> >> currently stands there’s a valid reason to use string literals. I was
> not
> >> suggesting changing anything.
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <[hidden email]>
> wrote:
> >>>
> >>> That sounds like the proper way to handle this! We should be able to
> >>> reference constants in our ActionScript so that we can get compile-time
> >>> errors from typos, while the compiler makes sure that generated
> >> JavaScript
> >>> can be properly minified.
> >>>
> >>> - Josh
> >>>
> >>> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <[hidden email]>
> >>> wrote:
> >>>
> >>>> AIUI, there is a cost in the minified JS to using constants.
> >>>>
> >>>> However, there is a cost to screwing up the typing of a string literal
> >> as
> >>>> well.
> >>>>
> >>>> The best answer for now, IMO, is to not care whether folks use
> constants
> >>>> or string literals.  There are much bigger fish to fry.  I don't want
> to
> >>>> see sweeping changes of replacing all string literals with constants
> or
> >>>> vice versa.  If you've got that kind of time on your hands, learn the
> >>>> compiler code and see if you can make the cross-compiler replace all
> >>>> constants with string literals.  IMO, that's the right answer.
> >>>>
> >>>> -Alex
> >>>>
> >>>> On 7/11/17, 5:37 AM, "Harbs" <[hidden email]> wrote:
> >>>>
> >>>>> Here’s what is output in the minimized code:
> >>>>>
> >>>>> function
> >>>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
> >>>> w('org.apache.flex
> >>>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
> >>>> HTTPConstants.PUT'
> >>>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
> >>>> ENCODED',Fm);w('org.
> >>>>> apache.flex.net.HTTPConstants.DELETE','DELETE'
> >>>> );w('org.apache.flex.net.HTT
> >>>>> PConstants.OPEN','open');w('org.apache.flex.net.
> >>>> HTTPConstants.COMPLETE',Bt
> >>>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
> >>>> ERROR',At);w('org.apa
> >>>>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
> >>>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
> >>>> 'securityError');w('o
> >>>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
> >>>> org.apache.flex.net.HTTPCo
> >>>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
> >>>> prototype.h={names:[{na
> >>>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
> >>>>>
> >>>>> elsewhere:
> >>>>> IF='org.apache.flex.net.HTTPConstants’,
> >>>>>
> >>>>> That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
> >>>>>
> >>>>> No idea what wiki you are referring to.
> >>>>>
> >>>>> Harbs
> >>>>>
> >>>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <
> [hidden email]>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>> As it stands now, use of constants result in more JS code after
> >>>>>>> compiled.
> >>>>>>
> >>>>>> Debug yes but not optimised / release.
> >>>>>>
> >>>>>>> It’s possible that this can be optimized, but currently the most
> >>>>>>> efficient JS code is produced if using string literals rather than
> >>>>>>> constants. (The Google compiler created variables for string
> literals
> >>>>>>> used more than once.)
> >>>>>>
> >>>>>> That's not we found in a previous thread on this list, the google
> >>>>>> compiler optimises the constants and there is no penalty in using
> >> them.
> >>>>>> You mind provide examples that show the above is the actually case
> and
> >>>>>> document it on the wiki?
> >>>>>>
> >>>>>> My vote would be not the duplicate the strings everywhere and use
> >>>>>> constants as there is no cost and increased safety.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Justin
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Alex Harui-2
Reflection support was opt-in.  Hopefully it still is.  As in, if your app
doesn't call any code that uses the reflection data structures they are
not in the minified output.

DataBinding in general requires exports.  Any use of bracket access does
as well.  But yes, I believe a smarter compiler can reduce the number of
exports.

I'm pretty sure --generate_exports is required to turn our @export
notation into symbols in the minified output.  But the main app has a
generated exportSymbol call so --generate_exports will not always be
required for FlexJS.

Again, though, I think this optimization isn't urgent.

goog.DEBUG is already being used in Language.as.

-Alex

On 7/11/17, 4:01 PM, "Greg Dove" <[hidden email]> wrote:

>I'll try those things, I have not tried any of those options so far.
>
>Future need to support modules has been mentioned as a reason for keeping
>@export before.
>
>Another is to support reflection (in its current form). Reflection support
>probably needs to be opt-in, I think this has been discussed before also.
>
>Perhaps another in this case might be to support constant bindings.
>This is one area that could probably benefit from jx-compiler optimisation
>for primitive constant lookups - iirc I *think* that constant bindings are
>still happening via bracket access, and probably could simply be replaced
>by the literal values for string, number etc.
>
>
>
>
>On Wed, Jul 12, 2017 at 9:57 AM, Harbs <[hidden email]> wrote:
>
>> Hi Greg,
>>
>> There probably is too much use of @export. @const is probably more
>>correct
>> than @export — as long as we are sure that there’s no use of bracket
>> notation anywhere. I’d be interested in hearing your findings.
>>
>> Personally, I’m not sure there’s a lot of value to be using @export at
>>all
>> unless an app is using modules of some sort (which I’m not even sure
>>how to
>> do with FlexJS). (but I might be missing something with the @export tag)
>>
>> What happens if the compiler is run without --generate_exports? Do the
>> @exports get stripped out? If yes, is there some kind of “super export”?
>> There needs to be some way to invoke the app…
>>
>> Harbs
>>
>> > On Jul 11, 2017, at 11:40 PM, Greg Dove <[hidden email]> wrote:
>> >
>> > Guys, we certainly have been here before.
>> >
>> > From a js release 'size' perspective, I don't think it matters
>>whether we
>> > use constants or liteterals, I think the main difference is that if
>>the
>> > static const exists it will also be included in the release output as
>>I
>> > expect it has an @export annotation. This means it should be
>> 'reflectable'
>> > via array/bracket access syntax via its original package/class naming.
>> But
>> > in terms of usage sites within the codebase, it should already be
>> optimised
>> > via GCC, becuase GCC is already capable of inlining anything annotated
>> as a
>> > constant [1].
>> > So I would expect it to already be inlined in the js-release, and we
>> > *should not need* to write any code in the jx compiler to do that,
>>unless
>> > we specifically need this inlining (for some reason) in the debug
>>version
>> > of the js output.
>> >
>> > GCC also creates a single short named variable to refer to repeated
>> > literals througout the compiled codebase, so I would expect the
>>inlining
>> of
>> > consts would get this as a 2nd optimization pass as well. In the end I
>> > expect the only output difference between the two approaches should be
>> that
>> > we also get an extra exported constant that retains the same naming
>> > convention of lookups etc because we are @export-ing it.
>> >
>> > I'm pretty sure this is correct, but I might be wrong. I will check
>>all
>> > this later today, and report back.
>> >
>> > 1.
>> >
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fgoogle%2Fclosure-compiler%2Fwiki%2F&data=02%7C01%7C%7Cb1383499ae944d
>>36cc6808d4c8b34fc5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636354119
>>847040656&sdata=1J07jc05ULQcd8VP01X2D4b6B62UHcEDTA71CS51O3s%3D&reserved=0
>> Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
>> >
>> >
>> >
>> > On Wed, Jul 12, 2017 at 3:47 AM, Harbs <[hidden email]> wrote:
>> >
>> >> +1.
>> >>
>> >> I also think that we have bigger fish to fry first.
>> >>
>> >> My point was not to force one way or the other. Rather that the way
>>it
>> >> currently stands there’s a valid reason to use string literals. I was
>> not
>> >> suggesting changing anything.
>> >>
>> >> Thanks,
>> >> Harbs
>> >>
>> >>> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <[hidden email]>
>> wrote:
>> >>>
>> >>> That sounds like the proper way to handle this! We should be able to
>> >>> reference constants in our ActionScript so that we can get
>>compile-time
>> >>> errors from typos, while the compiler makes sure that generated
>> >> JavaScript
>> >>> can be properly minified.
>> >>>
>> >>> - Josh
>> >>>
>> >>> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui
>><[hidden email]>
>> >>> wrote:
>> >>>
>> >>>> AIUI, there is a cost in the minified JS to using constants.
>> >>>>
>> >>>> However, there is a cost to screwing up the typing of a string
>>literal
>> >> as
>> >>>> well.
>> >>>>
>> >>>> The best answer for now, IMO, is to not care whether folks use
>> constants
>> >>>> or string literals.  There are much bigger fish to fry.  I don't
>>want
>> to
>> >>>> see sweeping changes of replacing all string literals with
>>constants
>> or
>> >>>> vice versa.  If you've got that kind of time on your hands, learn
>>the
>> >>>> compiler code and see if you can make the cross-compiler replace
>>all
>> >>>> constants with string literals.  IMO, that's the right answer.
>> >>>>
>> >>>> -Alex
>> >>>>
>> >>>> On 7/11/17, 5:37 AM, "Harbs" <[hidden email]> wrote:
>> >>>>
>> >>>>> Here’s what is output in the minimized code:
>> >>>>>
>> >>>>> function
>> >>>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
>> >>>> w('org.apache.flex
>> >>>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
>> >>>> HTTPConstants.PUT'
>> >>>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
>> >>>> ENCODED',Fm);w('org.
>> >>>>> apache.flex.net.HTTPConstants.DELETE','DELETE'
>> >>>> );w('org.apache.flex.net.HTT
>> >>>>> PConstants.OPEN','open');w('org.apache.flex.net.
>> >>>> HTTPConstants.COMPLETE',Bt
>> >>>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
>> >>>> ERROR',At);w('org.apa
>> >>>>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
>> >>>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
>> >>>> 'securityError');w('o
>> >>>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
>> >>>> org.apache.flex.net.HTTPCo
>> >>>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
>> >>>> prototype.h={names:[{na
>> >>>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
>> >>>>>
>> >>>>> elsewhere:
>> >>>>> IF='org.apache.flex.net.HTTPConstants’,
>> >>>>>
>> >>>>> That’s 807 bytes. That’s quite a penalty for avoiding typing
>>“POST”…
>> >>>>>
>> >>>>> No idea what wiki you are referring to.
>> >>>>>
>> >>>>> Harbs
>> >>>>>
>> >>>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <
>> [hidden email]>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>>> As it stands now, use of constants result in more JS code after
>> >>>>>>> compiled.
>> >>>>>>
>> >>>>>> Debug yes but not optimised / release.
>> >>>>>>
>> >>>>>>> It’s possible that this can be optimized, but currently the most
>> >>>>>>> efficient JS code is produced if using string literals rather
>>than
>> >>>>>>> constants. (The Google compiler created variables for string
>> literals
>> >>>>>>> used more than once.)
>> >>>>>>
>> >>>>>> That's not we found in a previous thread on this list, the google
>> >>>>>> compiler optimises the constants and there is no penalty in using
>> >> them.
>> >>>>>> You mind provide examples that show the above is the actually
>>case
>> and
>> >>>>>> document it on the wiki?
>> >>>>>>
>> >>>>>> My vote would be not the duplicate the strings everywhere and use
>> >>>>>> constants as there is no cost and increased safety.
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>> Justin
>> >>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Greg Dove
Reflection support was opt-in.  Hopefully it still is.  As in, if your app
doesn't call any code that uses the reflection data structures they are
not in the minified output.

I had not realised that (nor had I checked), that sounds great.


On Wed, Jul 12, 2017 at 5:20 PM, Alex Harui <[hidden email]>
wrote:

> Reflection support was opt-in.  Hopefully it still is.  As in, if your app
> doesn't call any code that uses the reflection data structures they are
> not in the minified output.
>
> DataBinding in general requires exports.  Any use of bracket access does
> as well.  But yes, I believe a smarter compiler can reduce the number of
> exports.
>
> I'm pretty sure --generate_exports is required to turn our @export
> notation into symbols in the minified output.  But the main app has a
> generated exportSymbol call so --generate_exports will not always be
> required for FlexJS.
>
> Again, though, I think this optimization isn't urgent.
>
> goog.DEBUG is already being used in Language.as.
>
> -Alex
>
> On 7/11/17, 4:01 PM, "Greg Dove" <[hidden email]> wrote:
>
> >I'll try those things, I have not tried any of those options so far.
> >
> >Future need to support modules has been mentioned as a reason for keeping
> >@export before.
> >
> >Another is to support reflection (in its current form). Reflection support
> >probably needs to be opt-in, I think this has been discussed before also.
> >
> >Perhaps another in this case might be to support constant bindings.
> >This is one area that could probably benefit from jx-compiler optimisation
> >for primitive constant lookups - iirc I *think* that constant bindings are
> >still happening via bracket access, and probably could simply be replaced
> >by the literal values for string, number etc.
> >
> >
> >
> >
> >On Wed, Jul 12, 2017 at 9:57 AM, Harbs <[hidden email]> wrote:
> >
> >> Hi Greg,
> >>
> >> There probably is too much use of @export. @const is probably more
> >>correct
> >> than @export — as long as we are sure that there’s no use of bracket
> >> notation anywhere. I’d be interested in hearing your findings.
> >>
> >> Personally, I’m not sure there’s a lot of value to be using @export at
> >>all
> >> unless an app is using modules of some sort (which I’m not even sure
> >>how to
> >> do with FlexJS). (but I might be missing something with the @export tag)
> >>
> >> What happens if the compiler is run without --generate_exports? Do the
> >> @exports get stripped out? If yes, is there some kind of “super export”?
> >> There needs to be some way to invoke the app…
> >>
> >> Harbs
> >>
> >> > On Jul 11, 2017, at 11:40 PM, Greg Dove <[hidden email]> wrote:
> >> >
> >> > Guys, we certainly have been here before.
> >> >
> >> > From a js release 'size' perspective, I don't think it matters
> >>whether we
> >> > use constants or liteterals, I think the main difference is that if
> >>the
> >> > static const exists it will also be included in the release output as
> >>I
> >> > expect it has an @export annotation. This means it should be
> >> 'reflectable'
> >> > via array/bracket access syntax via its original package/class naming.
> >> But
> >> > in terms of usage sites within the codebase, it should already be
> >> optimised
> >> > via GCC, becuase GCC is already capable of inlining anything annotated
> >> as a
> >> > constant [1].
> >> > So I would expect it to already be inlined in the js-release, and we
> >> > *should not need* to write any code in the jx compiler to do that,
> >>unless
> >> > we specifically need this inlining (for some reason) in the debug
> >>version
> >> > of the js output.
> >> >
> >> > GCC also creates a single short named variable to refer to repeated
> >> > literals througout the compiled codebase, so I would expect the
> >>inlining
> >> of
> >> > consts would get this as a 2nd optimization pass as well. In the end I
> >> > expect the only output difference between the two approaches should be
> >> that
> >> > we also get an extra exported constant that retains the same naming
> >> > convention of lookups etc because we are @export-ing it.
> >> >
> >> > I'm pretty sure this is correct, but I might be wrong. I will check
> >>all
> >> > this later today, and report back.
> >> >
> >> > 1.
> >> >
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.c
> >>om%2Fgoogle%2Fclosure-compiler%2Fwiki%2F&data=02%
> 7C01%7C%7Cb1383499ae944d
> >>36cc6808d4c8b34fc5%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636354119
> >>847040656&sdata=1J07jc05ULQcd8VP01X2D4b6B62UHc
> EDTA71CS51O3s%3D&reserved=0
> >> Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
> >> >
> >> >
> >> >
> >> > On Wed, Jul 12, 2017 at 3:47 AM, Harbs <[hidden email]> wrote:
> >> >
> >> >> +1.
> >> >>
> >> >> I also think that we have bigger fish to fry first.
> >> >>
> >> >> My point was not to force one way or the other. Rather that the way
> >>it
> >> >> currently stands there’s a valid reason to use string literals. I was
> >> not
> >> >> suggesting changing anything.
> >> >>
> >> >> Thanks,
> >> >> Harbs
> >> >>
> >> >>> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <[hidden email]>
> >> wrote:
> >> >>>
> >> >>> That sounds like the proper way to handle this! We should be able to
> >> >>> reference constants in our ActionScript so that we can get
> >>compile-time
> >> >>> errors from typos, while the compiler makes sure that generated
> >> >> JavaScript
> >> >>> can be properly minified.
> >> >>>
> >> >>> - Josh
> >> >>>
> >> >>> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui
> >><[hidden email]>
> >> >>> wrote:
> >> >>>
> >> >>>> AIUI, there is a cost in the minified JS to using constants.
> >> >>>>
> >> >>>> However, there is a cost to screwing up the typing of a string
> >>literal
> >> >> as
> >> >>>> well.
> >> >>>>
> >> >>>> The best answer for now, IMO, is to not care whether folks use
> >> constants
> >> >>>> or string literals.  There are much bigger fish to fry.  I don't
> >>want
> >> to
> >> >>>> see sweeping changes of replacing all string literals with
> >>constants
> >> or
> >> >>>> vice versa.  If you've got that kind of time on your hands, learn
> >>the
> >> >>>> compiler code and see if you can make the cross-compiler replace
> >>all
> >> >>>> constants with string literals.  IMO, that's the right answer.
> >> >>>>
> >> >>>> -Alex
> >> >>>>
> >> >>>> On 7/11/17, 5:37 AM, "Harbs" <[hidden email]> wrote:
> >> >>>>
> >> >>>>> Here’s what is output in the minimized code:
> >> >>>>>
> >> >>>>> function
> >> >>>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
> >> >>>> w('org.apache.flex
> >> >>>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
> >> >>>> HTTPConstants.PUT'
> >> >>>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
> >> >>>> ENCODED',Fm);w('org.
> >> >>>>> apache.flex.net.HTTPConstants.DELETE','DELETE'
> >> >>>> );w('org.apache.flex.net.HTT
> >> >>>>> PConstants.OPEN','open');w('org.apache.flex.net.
> >> >>>> HTTPConstants.COMPLETE',Bt
> >> >>>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
> >> >>>> ERROR',At);w('org.apa
> >> >>>>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
> >> >>>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
> >> >>>> 'securityError');w('o
> >> >>>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
> >> >>>> org.apache.flex.net.HTTPCo
> >> >>>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
> >> >>>> prototype.h={names:[{na
> >> >>>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
> >> >>>>>
> >> >>>>> elsewhere:
> >> >>>>> IF='org.apache.flex.net.HTTPConstants’,
> >> >>>>>
> >> >>>>> That’s 807 bytes. That’s quite a penalty for avoiding typing
> >>“POST”…
> >> >>>>>
> >> >>>>> No idea what wiki you are referring to.
> >> >>>>>
> >> >>>>> Harbs
> >> >>>>>
> >> >>>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <
> >> [hidden email]>
> >> >>>>>> wrote:
> >> >>>>>>
> >> >>>>>> Hi,
> >> >>>>>>
> >> >>>>>>> As it stands now, use of constants result in more JS code after
> >> >>>>>>> compiled.
> >> >>>>>>
> >> >>>>>> Debug yes but not optimised / release.
> >> >>>>>>
> >> >>>>>>> It’s possible that this can be optimized, but currently the most
> >> >>>>>>> efficient JS code is produced if using string literals rather
> >>than
> >> >>>>>>> constants. (The Google compiler created variables for string
> >> literals
> >> >>>>>>> used more than once.)
> >> >>>>>>
> >> >>>>>> That's not we found in a previous thread on this list, the google
> >> >>>>>> compiler optimises the constants and there is no penalty in using
> >> >> them.
> >> >>>>>> You mind provide examples that show the above is the actually
> >>case
> >> and
> >> >>>>>> document it on the wiki?
> >> >>>>>>
> >> >>>>>> My vote would be not the duplicate the strings everywhere and use
> >> >>>>>> constants as there is no cost and increased safety.
> >> >>>>>>
> >> >>>>>> Thanks,
> >> >>>>>> Justin
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>
> >> >>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Harbs
In reply to this post by Alex Harui-2

> On Jul 12, 2017, at 8:20 AM, Alex Harui <[hidden email]> wrote:
>
> Again, though, I think this optimization isn't urgent.

I completely agree. That’s why I have not been bringing this up despite it being on my mind. When the discussion came up, I couldn’t help but join. ;-)


> goog.DEBUG is already being used in Language.as.

Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in COMPILE::JS I’m guessing the imports of goog.bind and goog.global was enough to make goog.DEBUG visible to the compiler in Language.as.

Once we’re on this topic, there’s something that I had wanted to bring up for a long time: I think trace statements should disappear in the release JS build. Should we put all the JS trace code inside an if(goog.DEBUG)  block?

Thanks,
Harbs
Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Alex Harui-2
Well, the goal of using goog.DEBUG in Language.as trace() was to convince
GCC to eliminate trace().  I haven't checked whether it is working or not.
 Requiring everyone to use goog.DEBUG around trace statements sounds like
a pain.  Probably better to teach the publisher to remove it if GCC can't
be taught to do it.  We visit almost every line of the JS output in the
publishers right now.

My 2 cents,
-Alex

On 7/11/17, 11:47 PM, "Harbs" <[hidden email]> wrote:

>
>> On Jul 12, 2017, at 8:20 AM, Alex Harui <[hidden email]>
>>wrote:
>>
>> Again, though, I think this optimization isn't urgent.
>
>I completely agree. That’s why I have not been bringing this up despite
>it being on my mind. When the discussion came up, I couldn’t help but
>join. ;-)
>
>
>> goog.DEBUG is already being used in Language.as.
>
>Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in
>COMPILE::JS I’m guessing the imports of goog.bind and goog.global was
>enough to make goog.DEBUG visible to the compiler in Language.as.
>
>Once we’re on this topic, there’s something that I had wanted to bring up
>for a long time: I think trace statements should disappear in the release
>JS build. Should we put all the JS trace code inside an if(goog.DEBUG)
>block?
>
>Thanks,
>Harbs

Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Justin Mclean
Administrator
In reply to this post by Harbs
Hi,

> Once we’re on this topic, there’s something that I had wanted to bring up for a long time: I think trace statements should disappear in the release JS build. Should we put all the JS trace code inside an if(goog.DEBUG)  block?

I’d suggest putting in a static Log class/method that is does nothing if goog.DEBUG is false and traces goog.DEBUG is true. That way it makes easier to move to a real logging system at some point in the future.

Thanks,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST

Harbs
In reply to this post by Alex Harui-2
Oof. I think I’m still waking up. ;-)

I did not realize what I was looking at with the goog.DEBUG. My recollection is that trace statements are still being used in the release, but I’ll double check that.

> On Jul 12, 2017, at 9:56 AM, Alex Harui <[hidden email]> wrote:
>
> Well, the goal of using goog.DEBUG in Language.as trace() was to convince
> GCC to eliminate trace().  I haven't checked whether it is working or not.
> Requiring everyone to use goog.DEBUG around trace statements sounds like
> a pain.  Probably better to teach the publisher to remove it if GCC can't
> be taught to do it.  We visit almost every line of the JS output in the
> publishers right now.
>
> My 2 cents,
> -Alex
>
> On 7/11/17, 11:47 PM, "Harbs" <[hidden email]> wrote:
>
>>
>>> On Jul 12, 2017, at 8:20 AM, Alex Harui <[hidden email]>
>>> wrote:
>>>
>>> Again, though, I think this optimization isn't urgent.
>>
>> I completely agree. That’s why I have not been bringing this up despite
>> it being on my mind. When the discussion came up, I couldn’t help but
>> join. ;-)
>>
>>
>>> goog.DEBUG is already being used in Language.as.
>>
>> Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in
>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global was
>> enough to make goog.DEBUG visible to the compiler in Language.as.
>>
>> Once we’re on this topic, there’s something that I had wanted to bring up
>> for a long time: I think trace statements should disappear in the release
>> JS build. Should we put all the JS trace code inside an if(goog.DEBUG)
>> block?
>>
>> Thanks,
>> Harbs
>

12