On 3/14/17, 10:42 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>On Wed, Mar 15, 2017 at 6:33 PM, Alex Harui <aha...@adobe.com> wrote: > >> Here's a better link to the old thread. Looks like I did mess around >>with >> parseInt earlier. >> >> https://s.apache.org/rHq2 >> >> >> The goal is to match what AS does and get the performance benefit you >> measured and maybe prevent browsers from doing something strange. >> >> Hopefully it won't require sniffing the first parameter ourselves. >> >> Thanks, >> -Alex >> >> >> >Thanks for that link, the original was not working for me. >In theory it should simply take the string and deduce the radix internally >depending on whether the string has '0x' at the start or not. That's why >specifying the radix should always be faster. >But we cannot assume it is 10 for all strings in a compiler generated >version with the (apparently) mandatory second param for GCL. > >So it is a bit of challenge if we want to keep the AS behaviour, and if >the >GCL lib does not like having the second arg missing. >Basically for perfomance you need to specify the second param in the >native >version and that obviously will always be the better option. >I think the compiler generated version will need to do some sniffing >unfortunately, (if we are to keep behaviour) and will make that >performance >difference even more true, but will give it a bit more thought. >. I don't think there is any code at runtime that requires the second argument. We patch the files in the JS.swc so the second argument is optional. AFAIK, in the actual browser, the second parameter is optional. IMO, what you see in the original externs is Google's policy for their developers, not a runtime API spec. But you can see in the old thread that MDN says you really "should" set a second parameter. Somehow, that parseInt patch didn't work for Justin and you. So that's the first problem. Your flex-typedefs/js build should generate a parseInt.as with an optional second argument because the es3.js is patched to have an optional second argument. Then we can discuss whether the compiler should set 10 or 0 or trust the modern browsers to not think Octal or be unpredictable. Or make some other tradeoff like saying we're going to set 10 and you can't assume auto-conversion in FlexJS. Either way, we should clean up where we are using parseInt(, 10) in the FlexJS framework code. If you have time, it might be worth doing some tests in Flash and browser to see if you can set 10 in Flash and it will still sniff out hex, and whether using 0 works the same in both AS and JS. We have set a browser baseline of IE9 so we don't have to worry about really old browsers. Thanks, -Alex
