Right, and as far as I can tell, post-ES1 mathematical functions were subsequently added to Math rather than Number simply to be consistent with that status quo. Is that correct?

For example, in the notes, I see some old talk of making clz32 an instance method on Number.prototype, and later it got switched to a “static” method, presumably to avoid boxing primitive numbers. But I can’t really find any explicit reasoning why Math was chosen as its home instead of Number.

Yeah. An issue I’m going to raise during my BigInt Math presentation is that of max (and min and hypot). The issue is that if we simply extend Math.max to accept BigInts, then Math.max(…arrOfBigInts) would unexpectedly return +Infinity whenever arrOfBigInts happens to be empty—this would basically be an unexpected implicit type conversion from an array of BigInts to a Number value.

The choices I see are to either add a separate Math.bigMax function (and bigMin and bigHypot)…or add a BigInt.max method (in which case…why don’t we have Number.max—and then what about the other Math functions, do they get copied to Number and BigInt too?).

alternative guess: it's on the Math class because they were trying to script java

https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html

https://twitter.com/benawad/status/1263183829235269634?s=20

I wonder if a precision argument for Math.round might be worth pursuing………

class Foo(lib.Model):
  field1 = lib.Int()
  field2 = lib.String()

I think the thing I'd actually do with a decorator would be more like

@fields({ field1: lib.Int, field2: lib.String })
class Foo {
 ...
}

where @fields would replace the class with a subclass which called super and then validated and installed the fields named by the decorator

i.e. something like

@data
class C {
  x = data.int;
  constructor(obj) {
    data.init(obj);
    // other stuff
  }
}