What, exactly, is Math?

[lth]

What, exactly, is Math? if it’s a singleton class, how to limit access to its constructor? In ECMA-262, it’s an object, so it’s dynamic. But class objects are not dynamic. If it’s a singleton object, how to declare its methods in an early-bindable way? Should it be a package?

Builtin issue; probably resolved (we invented "intrinsic"); I think it's good to file this so that we look at it in detail to make sure it is compatible and early-bindable as desired.

Wiki location => proposals:builtin_classes

[lth]

The object Math (call it m) is the sole instance of a hidden dynamic class also called !Math. This provides m it with all the correct 3rd Ed semantics:

• m prints as [object Math]
• m can't be used as a function for purposes of construction or invocation
• Properties can be added to and removed from m
• Built-in properties on m are DontEnum
• Built-in method properties on m are writable and deletable
• Built-in value properties on m are ReadOnly and DontDelete

The internal Math class can't be subclassed because it's hidden.

We want to make it possible for early binding to properties of m, yet the !Math property of the global object is neither ReadOnly nor DontDelete. The scheduled bug fix IMMUTABLE.GLOBALS does not cover the case of the Math property. Instead we should provide for early binding by means of the intrinsic namespace:

• Define a global const property called intrinsic::Math whose type is known to be of the hidden Math class
• Provide for intrinsic static methods on the hidden Math class

Now any code that opens the intrinsic namespace to reference Math will access intrinsic::Math (in the absence of with and eval), and the compiler can know this. Furthermore the compiler knows that object's type, so can early-bind to both the constants and the methods.

[lth]

(Note, I'm leaving this ticket open until I've fixed a couple of issues in the code, but you should consider the ticket closed.)

[lth]

Also see #83.

[lth]

The intrinsic methods can't be static methods, because then they won't be visible through the object called Math, only through a class. They need to be instance methods instead. In a simple implementation they will be a little more expensive to call, but bound-this ensures that they have the right semantics -- they can be extracted as functions and called as functions. In an optimizing implementation they will be early-bound and the receiver is also early-bound; the implementation can special-case everything and inline the methods. There is no run-time cost.