-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normative: change default function length value to not include optional arguments #266
Conversation
(I count 59 explicit length removals, 16 explicit length additions) |
It would be good to list functions whose normative lengths have changed, even if we think their previous lengths were a bug. |
The only functions that applies to is the DataView ones:
Note that the "int 8" methods had no optional arguments, and thus were always 2 - this brings all the DataView get and set methods into alignment with 1 for get, and 2 for set - since they all have the same number of required arguments respectively. |
I thought e.g. Map's length changed, from previously 1 (since optional arguments were counted) to 0 (since now they are not). |
Map has always had an explicit length of |
<emu-note> | ||
<p>For example, the function object that is the initial value of the `slice` property of the String prototype object is described under the subclause heading “String.prototype.slice (start, end)” which shows the two named arguments start and end; therefore the value of the `length` property of that Function object is `2`.</p> | ||
<p>For example, the function object that is the initial value of the `map` property of the Array prototype object is described under the subclause heading «Array.prototype.map (callbackFn [ , thisArg])» which shows the two named arguments callbackFn and thisArg, the latter being optional; therefore the value of the `length` property of that Function object is `1`.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This note's language is needlessly pedantic but you can leave it :-P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind simplifying it, I just wanted to be explicit :-) Suggestions welcome.
44343a5
to
3cf8b06
Compare
6761173
to
3fd722e
Compare
…al arguments. Fixes tc39#264. - A few legacy methods that have deviating lengths are documented explicitly. - Any unneeded explicit lengths are removed. - Needed legacy explicit lengths are added. - Spacing inside optional argument brackets is made consistent - Fixed a bug with a `DataView` note having the wrong argument name The DataView prototype get/set methods have inconsistent lengths across all browsers, so rather than select one of them as legacy, I decided to let them fall into the default category, which hopefully implementations will align with. Here are the changes: - DataView.prototype.getFloat32 (sometimes 0 or 2, now 1) - DataView.prototype.getFloat64 (sometimes 0 or 2, now 1) - DataView.prototype.getInt16 (sometimes 0 or 2, now 1) - DataView.prototype.getInt32 (sometimes 0 or 2, now 1) - DataView.prototype.getUint16 (sometimes 0 or 2, now 1) - DataView.prototype.getUint32 (sometimes 0 or 2, now 1) - DataView.prototype.setFloat32 (sometimes 0 or 3, now 2) - DataView.prototype.setFloat64 (sometimes 0 or 3, now 2) - DataView.prototype.setInt16 (sometimes 0 or 3, now 2) - DataView.prototype.setInt32 (sometimes 0 or 3, now 2) - DataView.prototype.setUint16 (sometimes 0 or 3, now 2) - DataView.prototype.setUint32 (sometimes 0 or 3, now 2) Note that the "int 8" methods had no optional arguments, and thus were always 1 or 2 - this brings all the DataView get and set methods into alignment with 1 for get, and 2 for set - since they all have the same number of required arguments respectively.
3fd722e
to
5512445
Compare
Issues
|
... |
oops, will fix momentarily in a new PR |
I wanted to write proper review comments tomorrow, because I didn't expect this gets merged on a weekend. :-/ (The comments above are basically just my personal notes, that's why they're extra so brief. ) |
@anba re "length for Date is defined as part of 20.3.3" - should I remove it there and put it below the constructor like the rest? |
Sorry @anba :( Hopefully everything can be fixed in a subsequent PR? |
@ljharb I've just checked the other built-in constructors, except for the Array constructor, all constructor functions define their length property as part of the "Properties of the Constructor" section ("Besides the length property (whose value is ), the constructor has the following properties:"). I think I'd prefer if all built-in constructors have an explicit length definition (like the Array constructor), and the subordinate clauses in "Properties of the Constructor" are removed. @bterlson No worries. 😄 |
@anba agreed and done in the imminent PR! |
- Add missing tests for "length" property of built-in functions - Add missing tests for "name" property of built-in functions - Add basic surface tests for NativeErrors - Add basic surface tests for TypedArrays Notes: - Already uses the updated DataView function lengths from tc39/ecma262#266 (ES2016 Draft 2015-12-20)
…tions Note: Already uses the updated DataView function lengths from tc39/ecma262#266 (ES2016 Draft 2015-12-20)
…tions Note: Already uses the updated DataView function lengths from tc39/ecma262#266 (ES2016 Draft 2015-12-20)
Fixes #264.
DataView
note having the wrong argument nameThe DataView prototype get/set methods have inconsistent lengths across all browsers, so rather than select one of them as legacy, I decided to let them fall into the default category, which hopefully implementations will align with.