to clarify : I got the typedefs building eventually and compiling the single arg signature for partseInt is fine, but the compiler makes a fixed assumption for 10 radix for any string and adds that second param instead of allowing the native implementation to do its thing.
If there are string formats like octal that get inferred differently from the string in js but not in swf then that complicates things but if they are identical (and if there is no requirement to have the js output *not* have an optional argument) then the simplest thing of course is to pass it through unchanged. I will check the various browsers and permutations this weekend to see what happens. I already added a ticket for me On Wed, Mar 15, 2017 at 7:03 PM, Alex Harui <aha...@adobe.com> wrote: > > > 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 > >
