I think the problematic part is where strings start with "0". There might
be some browsers adding a radix of 8. This is a supposedly deprecated
feature. There is no way of knowing what the browser would do by default
in this case.
Thanks,
Om
On Tue, Mar 15, 2016 at 3:33 PM, Andy Dufilie <andy.dufi...@gmail.com>
wrote:
> All these return the same result, so I don't think we need to specify the
> second param. I think instead the extern file should be updated to make
> the second param optional.
>
> parseInt("0xFF00FF", 0)
> parseInt("0xFF00FF", undefined)
> parseInt("0xFF00FF")
>
>
> On Tue, Mar 15, 2016 at 4:52 PM, Alex Harui <aha...@adobe.com> wrote:
>
> >
> >
> > On 3/15/16, 1:49 PM, "Alex Harui" <aha...@adobe.com> wrote:
> >
> > >
> > >
> > >On 3/15/16, 1:35 PM, "Andy Dufilie" <andy.dufi...@gmail.com> wrote:
> > >
> > >>It's not a good idea to make built-in functions behave differently in
> JS
> > >>versus AS.
> > >>
> > >>It's not a required param in AS, and this change makes the following
> > >>evaluate to true in AS but false in the cross-compiled JS:
> > >>Number("0xFF00FF") == parseInt("0xFF00FF")
> > >
> > >Ah, good point. I didn't think about that case. So what do you suggest
> > >we do? We could map it to a new org.apache.flex.utils.Language.parseInt
> > >that checks the string for a leading "0x" and calls JS parseInt with the
> > >right radix. Or should we trust that all browsers we will actually use
> > >will "do the right thing"?
> >
> > Actually, reading the MDN article again, maybe we should set the second
> > param to 0 instead of 10?
> >
> > -Alex
> >
> >
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Ob
> > jects/parseInt
> >
> >
>
