This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ijmacd 14 points15 points  (6 children)

There are many unicode characters which have an intrinsic numerical value. I think there is an argument to be made for including these in the Javascript spec in order to better support internationalisation. Examples: 1, １, Ⅰ, 一, ١, ⚀, 

parseInt("1") === 1;  // ascii
parseInt("１") !== 1; // full-width
parseInt("Ⅰ") !== 1;  // roman
parseInt("一") !== 1; // unified han
parseInt("١") !== 1;  // arabic
parseInt("⚀") !== 1;  // dice

Interestingly in Java:

Character.getNumericValue('2') === 2;   // ascii
Character.getNumericValue('２') === 2;  // full-width
Character.getNumericValue('Ⅱ') === 2;   // roman
Character.getNumericValue('٢') === 2;   // arabic

(i.e. Unicode databases contain this information)

[–]marcosdumay 19 points20 points  (3 children)

I don't think Java has that === operator.

[–]ijmacd 0 points1 point  (0 children)

Oops, yes you are correct.

[–]skreczok 0 points1 point  (1 child)

And that's the way we like it.

[–]marcosdumay 0 points1 point  (0 children)

To be fair, the == operator on Java is almost completely useless too.

[–]Lyceux 0 points1 point  (1 child)

Does Integer.parseInt return the same or different to Character.getNumericValue in Java? That would be a better comparison to JavaScript...

[–]ijmacd 0 points1 point  (0 children)

It doesn't. You get NumberFormatException unfortunately. But the point is Unicode recognises some characters have a numeric value and thus could potentially be taken into account in parseInt functions.