flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Date Tue, 11 Jul 2017 21:57:19 GMT
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 <greg.dove@gmail.com> 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 <harbs.lists@gmail.com> 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 <joshtynjala@gmail.com> 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 <aharui@adobe.com.invalid>
>>> 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" <harbs.lists@gmail.com> 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 <justin@classsoftware.com>
>>>>>> 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
>>>>> 
>>>> 
>>>> 
>> 
>> 


Mime
View raw message