The current order of Number properties seems arbitrary and as a result appears jumbled.
Current:
20.1.2.1 Number.EPSILON
20.1.2.2 Number.isFinite ( number )
20.1.2.3 Number.isInteger ( number )
20.1.2.4 Number.isNaN ( number )
20.1.2.5 Number.isSafeInteger ( number )
20.1.2.6 Number.MAX_SAFE_INTEGER
20.1.2.7 Number.MAX_VALUE
20.1.2.8 Number.NaN
20.1.2.9 Number.NEGATIVE_INFINITY
20.1.2.10 Number.MIN_SAFE_INTEGER
20.1.2.11 Number.MIN_VALUE
20.1.2.12 Number.parseFloat ( string )
20.1.2.13 Number.parseInt ( string, radix )
20.1.2.14 Number.POSITIVE_INFINITY
Suggest:
20.1.2.1 Number.isFinite ( number )
20.1.2.2 Number.isInteger ( number )
20.1.2.3 Number.isNaN ( number )
20.1.2.4 Number.isSafeInteger ( number )
20.1.2.5 Number.parseFloat ( string )
20.1.2.6 Number.parseInt ( string, radix )
20.1.2.7 Number.EPSILON
20.1.2.8 Number.MAX_SAFE_INTEGER
20.1.2.9 Number.MAX_VALUE
20.1.2.10 Number.MIN_SAFE_INTEGER
20.1.2.11 Number.MIN_VALUE
20.1.2.12 Number.NaN
20.1.2.13 Number.NEGATIVE_INFINITY
20.1.2.14 Number.POSITIVE_INFINITY
well, they are in correct alphabetical order.
I could split them into two sections (value properties and function properties) like is done for Math, but I'd then have to include 'prototype' as a value property.
As alphabetical is the ordering that we normally use I don't see a lot of value in doing something different here.
(In reply to Allen Wirfs-Brock from comment #1)
> well, they are in correct alphabetical order.
Almost: Number.MIN_SAFE_INTEGER and Number.MIN_VALUE should be moved before Number.NaN.
fixed in rev28 editor's draft
well, at the placement of Number.NaN
I'm not going to argue against alphabetical ordering, I just thought that relative grouping might be easier to follow.
I agree with Waldron.
fixed in rev28