{[inert function]} from toString() for Math.random etc.

[dckc]

In a discussion of API evolution, @erights noted that for new features, testing for new properties by name works well, but for retroactive changes such as making Math.random() inert, it's unrealistic to expect code to test for absence of a property.

• code changes, unit tests as usual
• 262 test

IOU more explanation, but I have a meeting...

cc @phoddie

[erights]

Therefore, retroactive removal of standard function properties should replace them with a throw-only functions that throw a reasonable diagnostic explanation. Likewise, perhaps, retroactive removal of data properties should turn them into throw-only accessors. This seems more unpleasant, but is also exceedingly rare.

[phoddie]

This guidance is consist with what XS has long done when minimizing a VM for embedded targets. For example, when the XS linker determines that a project does not use Math.cos(), instead of deleting cos, the linker replaces the implementation with a stub function that throws. The stub function should never be invoked, but is there to provide a diagnostic just in case.

[erights]

Good, that's what I expected.

SES is not yet doing this, so this bug remains open for us

[phoddie]

Since we are on the topic... in secure mode, the XS implementation of SES replaces Math.random() with a function that throws a TypeError with the message "secure mode". Date.now() and appropriate paths of the Date constructor throw the same error.

[erights]

See #1664

[erights]

See especially thread starting at #1664 (review) . Conclusion is that the SES shim should only poison Date.now, the relevant portion of the Date constructor behavior, and the Math.random function. All the rest of the censored properties should continue to be censored by removal, as they are now.

Some odd cases worth discussing:

• RegExp.prototype.compile predates ES5 and does not shadow anything inherited, so by the criteria of that thread it might seem we should poison it instead. However, it is already in Annex B as Normative Optional, so it is already coherent to expect programs that care to probe for it with property testing style.
• RegExp.$1 etc. These are non-standard, and proposed only to become standard as Normative Optional. So again, we can expect property testing style.
• Object.prototype.__proto__. We currently support it, as it does not violate any hard ocap safety rule. However, it is now (thankfully!) classified as Normative Optional, so if we ever do censor it, it is sensible for us to censor it by removal, requiring programs that use it to probe using property testing style. This is perhaps a bit more delicate because significant time passed between when it became standard mandatory and when it was demoted to Normative Optional.
• Object.prototype.__defineGetter__, etc. In theory the same as __proto__. The difference is that we are likely to retire __proto__ for safety reasons @caridy has explained. By contrast, there is no known reason to censor the __defineGetter__ etc properties.