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

[Alex Harui]

I'm unable to gather from this thread what code is being generated and
what errors are being generated when it doesn't work.

-Alex

On 7/12/17, 12:39 PM, "Harbs"  wrote:

>I tried on a simpler project and the only thing being output is a trace
>declaration with an empty function:
>u('org.apache.flex.utils.Language.trace',m());
>
>All calls to trace() are stripped out by the google compiler.
>
>This looks to be the case even without modifying the Language.trace
>output.
>
>FWIW, This is with -remove-circulars. When I tried to compile without
>-remove-circulars it had all kinds of runtime errors including calls to
>non-existent trace functions. I don’t know hwy. The project is really
>simple, and I’d think -remove-circulars should not be required.
>
>I have no idea why my more complex project outputs trace differently…
>
>Harbs
>
>> On Jul 12, 2017, at 8:11 PM, Harbs  wrote:
>> 
>> Maybe I’m doing something wrong, but I get the following error when I
>>tried using -skip-transpile:
>> 
>> [java] java.lang.NullPointerException
>>org.apache.flex.compiler.internal.projects.FlexJSProject.computeTargetAtt
>>ributes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.
>>mxml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:55
>>4)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublish
>>er.publish(MXMLFlexJSPublisher.java:345)org.apache.flex.compiler.clients.
>>MXMLJSCFlex.compile(MXMLJSCFlex.java:387)org.apache.flex.compiler.clients
>>.MXMLJSCFlex._mainNoExit(MXMLJSCFlex.java:245)org.apache.flex.compiler.cl
>>ients.MXMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compile
>>r.clients.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.c
>>lients.MXMLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clien
>>ts.MXMLJSC.staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.cli
>>ents.MXMLJSC.main(MXMLJSC.java:229)
>> [java]
>> [java]
>> [java] Java Result: 3
>> 
>>> On Jul 12, 2017, at 7:48 PM, Alex Harui 
>>>wrote:
>>> 
>>> Trace supports multiple parameters and concatenates them with " "
>>> in-between.
>>> 
>>> If you want to investigate more, you can use -sdk-js-lib to point to a
>>> hacked version of Language.js with goog.DEBUG around the "rest" code.
>>> 
>>> I think you can also just modify what is in bin/js-debug and run the
>>> compiler with the -skip-transpile option and it won't re-transpile and
>>> just pass js-debug files to GCC and generate a new js-release output.
>>> 
>>> -Alex
>>> 
>>> On 7/12/17, 9:11 AM, "Harbs"  wrote:
>>> 
 That line was what was left of the trace function.
 
 The reason the trace function is not completely empty is because it
has
 this code generated from "…rest” at the start of the function:
 rest = Array.prototype.slice.call(arguments, 0);
 
 I have no idea why that code is necessary. Maybe if it was not
generated
 and the function was truly empty, the trace calls would be stripped
out
 as well?
 
 Leftover trace calls elsewhere in the code look something like this:
 uM('unexpected condition in deferredBindingsHandler’);
 
> On Jul 12, 2017, at 6:08 PM, Alex Harui 
> wrote:
> 
> If it were up to me, we'd strip traces based on the optimize compiler
> option.  I think that's how it worked in the Flex SDK.
> 
> I thought GCC had enough dead-code-removal logic to remove
> Language.trace
> once it saw that trace effectively did nothing.
> 
> I can't seem to piece together from this thread what the original AS
>was
> and what the un-minified JS output was.  Maybe there's something
>about
> the
> JS output that isn't right.  It is strange to see the string name of
>the
> trace function.
> 
> Regarding a logging system, I think folks are just used to trace and
>the
> cool thing about JS right now is that you can replace functions at
> runtime, so a logging bead would just replace Language.trace().
> 
> -Alex
> 
> On 7/12/17, 6:44 AM, "Harbs"  wrote:
> 
>> Interesting scenarios. I would not have thought of that.
>> 
>> If we could figure out how to strip the function call and leave the
>> parameter, the compiler would strip out the contents if it could be
>> safely removed.
>> 
>> So trace(“something”) would become “something” which is en empty
>> statement and would be stripped out.
>> 
>> Of course, I have no idea how to go about doing that… ;-)
>> 
>> Harbs
>> 
>>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala 
>>> wrote:
>>> 
>>> Probably the same with function calls too:
>>> 
>>> trace(someFunction());
>>> 
>>> They wanted this to remain:
>>> 
>>> someFunction();

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

[Harbs]

I tried on a simpler project and the only thing being output is a trace 
declaration with an empty function:
u('org.apache.flex.utils.Language.trace',m());

All calls to trace() are stripped out by the google compiler.

This looks to be the case even without modifying the Language.trace output.

FWIW, This is with -remove-circulars. When I tried to compile without 
-remove-circulars it had all kinds of runtime errors including calls to 
non-existent trace functions. I don’t know hwy. The project is really simple, 
and I’d think -remove-circulars should not be required.

I have no idea why my more complex project outputs trace differently…

Harbs

> On Jul 12, 2017, at 8:11 PM, Harbs  wrote:
> 
> Maybe I’m doing something wrong, but I get the following error when I tried 
> using -skip-transpile:
> 
> [java] java.lang.NullPointerException 
> org.apache.flex.compiler.internal.projects.FlexJSProject.computeTargetAttributes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:554)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.publish(MXMLFlexJSPublisher.java:345)org.apache.flex.compiler.clients.MXMLJSCFlex.compile(MXMLJSCFlex.java:387)org.apache.flex.compiler.clients.MXMLJSCFlex._mainNoExit(MXMLJSCFlex.java:245)org.apache.flex.compiler.clients.MXMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clients.MXMLJSC.staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:229)
> [java]
> [java]
> [java] Java Result: 3
> 
>> On Jul 12, 2017, at 7:48 PM, Alex Harui  wrote:
>> 
>> Trace supports multiple parameters and concatenates them with " "
>> in-between.
>> 
>> If you want to investigate more, you can use -sdk-js-lib to point to a
>> hacked version of Language.js with goog.DEBUG around the "rest" code.
>> 
>> I think you can also just modify what is in bin/js-debug and run the
>> compiler with the -skip-transpile option and it won't re-transpile and
>> just pass js-debug files to GCC and generate a new js-release output.
>> 
>> -Alex
>> 
>> On 7/12/17, 9:11 AM, "Harbs"  wrote:
>> 
>>> That line was what was left of the trace function.
>>> 
>>> The reason the trace function is not completely empty is because it has
>>> this code generated from "…rest” at the start of the function:
>>> rest = Array.prototype.slice.call(arguments, 0);
>>> 
>>> I have no idea why that code is necessary. Maybe if it was not generated
>>> and the function was truly empty, the trace calls would be stripped out
>>> as well?
>>> 
>>> Leftover trace calls elsewhere in the code look something like this:
>>> uM('unexpected condition in deferredBindingsHandler’);
>>> 
 On Jul 12, 2017, at 6:08 PM, Alex Harui 
 wrote:
 
 If it were up to me, we'd strip traces based on the optimize compiler
 option.  I think that's how it worked in the Flex SDK.
 
 I thought GCC had enough dead-code-removal logic to remove
 Language.trace
 once it saw that trace effectively did nothing.
 
 I can't seem to piece together from this thread what the original AS was
 and what the un-minified JS output was.  Maybe there's something about
 the
 JS output that isn't right.  It is strange to see the string name of the
 trace function.
 
 Regarding a logging system, I think folks are just used to trace and the
 cool thing about JS right now is that you can replace functions at
 runtime, so a logging bead would just replace Language.trace().
 
 -Alex
 
 On 7/12/17, 6:44 AM, "Harbs"  wrote:
 
> Interesting scenarios. I would not have thought of that.
> 
> If we could figure out how to strip the function call and leave the
> parameter, the compiler would strip out the contents if it could be
> safely removed.
> 
> So trace(“something”) would become “something” which is en empty
> statement and would be stripped out.
> 
> Of course, I have no idea how to go about doing that… ;-)
> 
> Harbs
> 
>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala 
>> wrote:
>> 
>> Probably the same with function calls too:
>> 
>> trace(someFunction());
>> 
>> They wanted this to remain:
>> 
>> someFunction();
>> 
>> - Josh
>> 
>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala 
>> wrote:
>> 
>>> One thing to keep in mind with stripping out trace() calls is that
>>> some
>>> developers expect any modifications to variables that happen inside
>>> the
>>> arguments to remain. I remember a while back 

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

[Harbs]

Maybe I’m doing something wrong, but I get the following error when I tried 
using -skip-transpile:

 [java] java.lang.NullPointerException 
org.apache.flex.compiler.internal.projects.FlexJSProject.computeTargetAttributes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:554)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.publish(MXMLFlexJSPublisher.java:345)org.apache.flex.compiler.clients.MXMLJSCFlex.compile(MXMLJSCFlex.java:387)org.apache.flex.compiler.clients.MXMLJSCFlex._mainNoExit(MXMLJSCFlex.java:245)org.apache.flex.compiler.clients.MXMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clients.MXMLJSC.staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:229)
 [java]
 [java]
 [java] Java Result: 3

> On Jul 12, 2017, at 7:48 PM, Alex Harui  wrote:
> 
> Trace supports multiple parameters and concatenates them with " "
> in-between.
> 
> If you want to investigate more, you can use -sdk-js-lib to point to a
> hacked version of Language.js with goog.DEBUG around the "rest" code.
> 
> I think you can also just modify what is in bin/js-debug and run the
> compiler with the -skip-transpile option and it won't re-transpile and
> just pass js-debug files to GCC and generate a new js-release output.
> 
> -Alex
> 
> On 7/12/17, 9:11 AM, "Harbs"  wrote:
> 
>> That line was what was left of the trace function.
>> 
>> The reason the trace function is not completely empty is because it has
>> this code generated from "…rest” at the start of the function:
>> rest = Array.prototype.slice.call(arguments, 0);
>> 
>> I have no idea why that code is necessary. Maybe if it was not generated
>> and the function was truly empty, the trace calls would be stripped out
>> as well?
>> 
>> Leftover trace calls elsewhere in the code look something like this:
>> uM('unexpected condition in deferredBindingsHandler’);
>> 
>>> On Jul 12, 2017, at 6:08 PM, Alex Harui 
>>> wrote:
>>> 
>>> If it were up to me, we'd strip traces based on the optimize compiler
>>> option.  I think that's how it worked in the Flex SDK.
>>> 
>>> I thought GCC had enough dead-code-removal logic to remove
>>> Language.trace
>>> once it saw that trace effectively did nothing.
>>> 
>>> I can't seem to piece together from this thread what the original AS was
>>> and what the un-minified JS output was.  Maybe there's something about
>>> the
>>> JS output that isn't right.  It is strange to see the string name of the
>>> trace function.
>>> 
>>> Regarding a logging system, I think folks are just used to trace and the
>>> cool thing about JS right now is that you can replace functions at
>>> runtime, so a logging bead would just replace Language.trace().
>>> 
>>> -Alex
>>> 
>>> On 7/12/17, 6:44 AM, "Harbs"  wrote:
>>> 
 Interesting scenarios. I would not have thought of that.
 
 If we could figure out how to strip the function call and leave the
 parameter, the compiler would strip out the contents if it could be
 safely removed.
 
 So trace(“something”) would become “something” which is en empty
 statement and would be stripped out.
 
 Of course, I have no idea how to go about doing that… ;-)
 
 Harbs
 
> On Jul 12, 2017, at 4:32 PM, Josh Tynjala 
> wrote:
> 
> Probably the same with function calls too:
> 
> trace(someFunction());
> 
> They wanted this to remain:
> 
> someFunction();
> 
> - Josh
> 
> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala 
> wrote:
> 
>> One thing to keep in mind with stripping out trace() calls is that
>> some
>> developers expect any modifications to variables that happen inside
>> the
>> arguments to remain. I remember a while back someone at Adobe
>> mentioning
>> that people complained when something like this was completely
>> stripped out:
>> 
>> trace(doSomething++);
>> 
>> Because they expected this part to remain:
>> 
>> doSomething++;
>> 
>> - Josh
>> 
>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs 
>> wrote:
>> 
>>> My bad. It does in fact compile down to this:
>>> 
>>> function 
>>> uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>> e.flex.utils.Language.trace',uM);
>>> 
>>> So trace does not actually do anything. Great! :-)
>>> 
>>> However, it’s still being called by the client code. (It just does
>>> nothing.) Not super important, but it would be nice if at some point
>>> we can
>>> figure out 

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

[Alex Harui]

If it were up to me, we'd strip traces based on the optimize compiler
option.  I think that's how it worked in the Flex SDK.

I thought GCC had enough dead-code-removal logic to remove Language.trace
once it saw that trace effectively did nothing.

I can't seem to piece together from this thread what the original AS was
and what the un-minified JS output was.  Maybe there's something about the
JS output that isn't right.  It is strange to see the string name of the
trace function.

Regarding a logging system, I think folks are just used to trace and the
cool thing about JS right now is that you can replace functions at
runtime, so a logging bead would just replace Language.trace().

-Alex

On 7/12/17, 6:44 AM, "Harbs"  wrote:

>Interesting scenarios. I would not have thought of that.
>
>If we could figure out how to strip the function call and leave the
>parameter, the compiler would strip out the contents if it could be
>safely removed.
>
>So trace(“something”) would become “something” which is en empty
>statement and would be stripped out.
>
>Of course, I have no idea how to go about doing that… ;-)
>
>Harbs
>
>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala  wrote:
>> 
>> Probably the same with function calls too:
>> 
>> trace(someFunction());
>> 
>> They wanted this to remain:
>> 
>> someFunction();
>> 
>> - Josh
>> 
>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala 
>>wrote:
>> 
>>> One thing to keep in mind with stripping out trace() calls is that some
>>> developers expect any modifications to variables that happen inside the
>>> arguments to remain. I remember a while back someone at Adobe
>>>mentioning
>>> that people complained when something like this was completely
>>>stripped out:
>>> 
>>> trace(doSomething++);
>>> 
>>> Because they expected this part to remain:
>>> 
>>> doSomething++;
>>> 
>>> - Josh
>>> 
>>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs  wrote:
>>> 
 My bad. It does in fact compile down to this:
 
 function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
 e.flex.utils.Language.trace',uM);
 
 So trace does not actually do anything. Great! :-)
 
 However, it’s still being called by the client code. (It just does
 nothing.) Not super important, but it would be nice if at some point
we can
 figure out if there’s a way to strip out the calls completely.
 
> On Jul 12, 2017, at 10:07 AM, Harbs  wrote:
> 
> 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 
 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"  wrote:
>> 
>>> 
 On Jul 12, 2017, at 8:20 AM, Alex Harui 
 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
>> 
> 
 
 
>>> 
>

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

[Harbs]

Interesting scenarios. I would not have thought of that.

If we could figure out how to strip the function call and leave the parameter, 
the compiler would strip out the contents if it could be safely removed.

So trace(“something”) would become “something” which is en empty statement and 
would be stripped out.

Of course, I have no idea how to go about doing that… ;-)

Harbs

> On Jul 12, 2017, at 4:32 PM, Josh Tynjala  wrote:
> 
> Probably the same with function calls too:
> 
> trace(someFunction());
> 
> They wanted this to remain:
> 
> someFunction();
> 
> - Josh
> 
> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala  wrote:
> 
>> One thing to keep in mind with stripping out trace() calls is that some
>> developers expect any modifications to variables that happen inside the
>> arguments to remain. I remember a while back someone at Adobe mentioning
>> that people complained when something like this was completely stripped out:
>> 
>> trace(doSomething++);
>> 
>> Because they expected this part to remain:
>> 
>> doSomething++;
>> 
>> - Josh
>> 
>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs  wrote:
>> 
>>> My bad. It does in fact compile down to this:
>>> 
>>> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>> e.flex.utils.Language.trace',uM);
>>> 
>>> So trace does not actually do anything. Great! :-)
>>> 
>>> However, it’s still being called by the client code. (It just does
>>> nothing.) Not super important, but it would be nice if at some point we can
>>> figure out if there’s a way to strip out the calls completely.
>>> 
 On Jul 12, 2017, at 10:07 AM, Harbs  wrote:
 
 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 
>>> 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"  wrote:
> 
>> 
>>> On Jul 12, 2017, at 8:20 AM, Alex Harui 
>>> 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
> 
 
>>> 
>>> 
>> 

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

[Josh Tynjala]

Probably the same with function calls too:

trace(someFunction());

They wanted this to remain:

someFunction();

- Josh

On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala  wrote:

> One thing to keep in mind with stripping out trace() calls is that some
> developers expect any modifications to variables that happen inside the
> arguments to remain. I remember a while back someone at Adobe mentioning
> that people complained when something like this was completely stripped out:
>
> trace(doSomething++);
>
> Because they expected this part to remain:
>
> doSomething++;
>
> - Josh
>
> On Wed, Jul 12, 2017 at 12:24 AM, Harbs  wrote:
>
>> My bad. It does in fact compile down to this:
>>
>> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>> e.flex.utils.Language.trace',uM);
>>
>> So trace does not actually do anything. Great! :-)
>>
>> However, it’s still being called by the client code. (It just does
>> nothing.) Not super important, but it would be nice if at some point we can
>> figure out if there’s a way to strip out the calls completely.
>>
>> > On Jul 12, 2017, at 10:07 AM, Harbs  wrote:
>> >
>> > 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 
>> 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"  wrote:
>> >>
>> >>>
>>  On Jul 12, 2017, at 8:20 AM, Alex Harui 
>>  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
>> >>
>> >
>>
>>
>

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

[Josh Tynjala]

One thing to keep in mind with stripping out trace() calls is that some
developers expect any modifications to variables that happen inside the
arguments to remain. I remember a while back someone at Adobe mentioning
that people complained when something like this was completely stripped out:

trace(doSomething++);

Because they expected this part to remain:

doSomething++;

- Josh

On Wed, Jul 12, 2017 at 12:24 AM, Harbs  wrote:

> My bad. It does in fact compile down to this:
>
> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.
> apache.flex.utils.Language.trace',uM);
>
> So trace does not actually do anything. Great! :-)
>
> However, it’s still being called by the client code. (It just does
> nothing.) Not super important, but it would be nice if at some point we can
> figure out if there’s a way to strip out the calls completely.
>
> > On Jul 12, 2017, at 10:07 AM, Harbs  wrote:
> >
> > 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 
> 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"  wrote:
> >>
> >>>
>  On Jul 12, 2017, at 8:20 AM, Alex Harui 
>  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
> >>
> >
>
>

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

[Harbs]

Like I said, it would be nice to figure out how to remove it completely.

It’s not awfully expensive though. It’s a simple copy of an array with a single 
string.

> On Jul 12, 2017, at 11:52 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> function 
>> uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apache.flex.utils.Language.trace',uM);
> 
> I could be wrong but wouldn’t the call to Array.prototype.slice still be 
> rather expensive?
> 
> Thanks,
> Justin

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

[Justin Mclean]

Hi,

> function 
> uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apache.flex.utils.Language.trace',uM);

I could be wrong but wouldn’t the call to Array.prototype.slice still be rather 
expensive?

Thanks,
Justin

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

[Harbs]

I don’t know. I don’t use logging nearly as much as I probably should.

I was just pointing out the goog.log package on the JS side in case you want to 
implement something.

Thanks,
Harbs

> On Jul 12, 2017, at 10:39 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> It might be nice to have a generic cross-platform logging package.
> 
> Like mx.logging perhaps? Or Apache common logging as there's an AS version of 
> that? I don’t imagine either would be hard to make cross platform.
> 
> Thanks,
> Justin

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

[Justin Mclean]

Hi,

> It might be nice to have a generic cross-platform logging package.

Like mx.logging perhaps? Or Apache common logging as there's an AS version of 
that? I don’t imagine either would be hard to make cross platform.

Thanks,
Justin

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

[Harbs]

There is a goog.log package.[1]

Unless I’m mistaken, those calls are removed by the compiler.

It might be nice to have a generic cross-platform logging package.

[1]https://google.github.io/closure-library/api/goog.log.html 

> On Jul 12, 2017, at 10:06 AM, Justin Mclean  wrote:
> 
> 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

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

[Harbs]

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  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"  wrote:
> 
>> 
>>> On Jul 12, 2017, at 8:20 AM, Alex Harui 
>>> 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
> 

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

[Harbs]

My bad. It does in fact compile down to this:

function 
uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apache.flex.utils.Language.trace',uM);

So trace does not actually do anything. Great! :-)

However, it’s still being called by the client code. (It just does nothing.) 
Not super important, but it would be nice if at some point we can figure out if 
there’s a way to strip out the calls completely.

> On Jul 12, 2017, at 10:07 AM, Harbs  wrote:
> 
> 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  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"  wrote:
>> 
>>> 
 On Jul 12, 2017, at 8:20 AM, Alex Harui 
 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
>> 
> 

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

[Justin Mclean]

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

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

[Alex Harui]

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"  wrote:

>
>> On Jul 12, 2017, at 8:20 AM, Alex Harui 
>>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

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

[Harbs]

> On Jul 12, 2017, at 8:20 AM, Alex Harui  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

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 
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"  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  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  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=02%
> 7C01%7C%7Cb1383499ae944d
> >>36cc6808d4c8b34fc5%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636354119
> >>847040656=1J07jc05ULQcd8VP01X2D4b6B62UHc
> EDTA71CS51O3s%3D=0
> >> Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
> >> >
> >> >
> >> >
> >> > On Wed, Jul 12, 2017 at 3:47 AM, Harbs  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
> 

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

[Alex Harui]

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"  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  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  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=02%7C01%7C%7Cb1383499ae944d
>>36cc6808d4c8b34fc5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636354119
>>847040656=1J07jc05ULQcd8VP01X2D4b6B62UHcEDTA71CS51O3s%3D=0
>> Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
>> >
>> >
>> >
>> > On Wed, Jul 12, 2017 at 3:47 AM, Harbs  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 
>> 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
>>
>> >>> 

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  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  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  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 
> 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 
> >>> 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"  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_
>  

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  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  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  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 
>>> 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"  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, 

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

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

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

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

[Alex Harui]

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

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

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

[Justin Mclean]

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

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

[Yishay Weiss]

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:piotrzarzyck...@gmail.com>
Sent: Tuesday, July 11, 2017 12:05 PM
To: dev@flex.apache.org<mailto:dev@flex.apache.org>
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
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.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.

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

[piotrz]

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



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-Uploads-are-assumed-to-be-POST-tp63070p63082.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

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 <piotrzarzyck...@gmail.com> 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
> piotrzarzyck...@gmail.com
> --
> 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.

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



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.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.

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

[Yishay Weiss]

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

From: Piotr Zarzycki<mailto:piotrzarzyck...@gmail.com>
Sent: Tuesday, July 11, 2017 11:15 AM
To: dev@flex.apache.org<mailto:dev@flex.apache.org>
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 <yish...@apache.org>:

> 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 <yishayj...@hotmail.com>
> Authored: Tue Jul 11 11:08:32 2017 +0300
> Committer: DESKTOP-RH4S838\Yishay <yishayj...@hotmail.com>
> 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);
>
>

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

[Piotr Zarzycki]

Hi Yishay,

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

Thanks, Piotr

2017-07-11 10:09 GMT+02:00 :

> 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 
> Authored: Tue Jul 11 11:08:32 2017 +0300
> Committer: DESKTOP-RH4S838\Yishay 
> 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);
>
>