Number handling

# Yehuda Katz (18 years ago)

After playing with the ES4 RI yesterday, my biggest concern comes from the handling of various number types as compared to other types:

  • Literal numbers become ints, rather than Numbers. While ES4 is still compatible with ES3 via some very strange use of the constructor property, doing something like: var x:Number; x = 7; throws an error.
  • ints are coercive by default. So function foo(x:int) { return x }; foo(null) returns 0, while function foo(x:Number) { return x }; foo(null) returns null. In effect function foo(x:int) { return x } is identical to function foo(x:*) { return new int(x) }
  • This is the same for all "primitives" like double.
  • I understand that this does not break strict compatibility with ES3, but it certainly breaks conceptual compatibility, because adding in simple typechecking to an existing ES3 app will break things unless the programmer learns the new paradigm for handling primitives.

Of course, it's possible that some of this is just a failing in the reference implementation, but looking through the available materials leads me to believe that it's not all RI-related.

# Brendan Eich (18 years ago)

On Oct 30, 2007, at 12:55 PM, Yehuda Katz wrote:

After playing with the ES4 RI yesterday, my biggest concern comes
from the handling of various number types as compared to other types:

  • Literal numbers become ints, rather than Numbers. While ES4 is
    still compatible with ES3 via some very strange use of the
    constructor property, doing something like: var x:Number; x = 7;
    throws an error.

As noted, an RI bug (apologies again). The ES4 proposal calls for
interconversion among the types in AnyNumber.

  • ints are coercive by default. So function foo(x:int) { return
    x }; foo(null) returns 0, while function foo(x:Number) { return
    x }; foo(null) returns null. In effect function foo(x:int) { return
    x } is identical to function foo(x:*) { return new int(x) }

More RI bugs. See bugs.ecmascript.org/ticket/113.

  • This is the same for all "primitives" like double.

When fixed (some of the problem has been fixed already), only for all
members of AnyNumber. Current RI:

$ make repl perl bin/repl-with-readline.pl

var i:int = 3.14 var j:double = 7 var k:int = "moo" [locn] builtins/Error.es:86:55-86.55 [stack] [init k()] ERROR EvalError: uncaught exception: TypeError: incompatible
types w/o conversion: val="moo" type=[ns public 'ES4']::string
wanted=[ns public 'ES4']::int (near builtins/Error.es:86:55-86.55)

var l:double = "oink" [stack] [init k() | init l()] ERROR EvalError: uncaught exception: TypeError: incompatible
types w/o conversion: val="oink" type=[ns public 'ES4']::string
wanted=[ns public 'ES4']::double (near builtins/Error.es: 86:55-86.55)

Of course, it's possible that some of this is just a failing in the
reference implementation, but looking through the available
materials leads me to believe that it's not all RI-related.

It is all RI-related, sorry again. The proposals and especially the
overview are clearer about interconversion only among AnyNumber
members. And ticket 113 is there to remind us.