Editorial: Use tildes for spec-internal values wherever possible.#1725
Editorial: Use tildes for spec-internal values wherever possible.#1725ljharb merged 1 commit intotc39:masterfrom
Conversation
|
This seems good, but more eyes is better. Also, can we add something about tilde-d things to a new section in https://tc39.es/ecma262/#sec-notational-conventions, either a 5.3, or a 5.2.6? |
|
We absolutely need such a section (not just for tildes but also asterisks, etc.), but I was hoping to address this in a separate PR. Is that okay? |
|
I suppose, but I worry that without the section, the drift will continue - is there a reason it has to be delayed, or a rush to merge this one? |
|
Sorry, I didn't mean to imply any sort of chronology or delay; I just thought it would be deserving of its own review thread. |
|
Hopefully it would be no more controversial than this very PR :-) |
|
Added a section 5.2.6. |
jmdyck
left a comment
jmdyck
left a comment
There was a problem hiding this comment.
Problem: when passing a TypedArray element-type to the _type_ parameter of:
- GetValueFromBuffer,
- SetValueInBuffer,
- GetModifySetValueInBuffer, and
- NumericToRawBytes,
sometimes the argument is a String value, and sometimes it's a tilde-value.
One way to resolve this would be to simply undo the String -> tilde change for these values.
If instead you want to go "forward", then I think you'd need to:
- change
the String value of the Element Type value ...to justthe Element Type value ... - In the TypedArray Constructors table, put the Element Type values in tildes.
- change 3
SameValueinvocations (the ones involving_srcType_) tois the same as/is different from(becauseSameValueis defined to only take language values).
|
Thanks for noticing that, @jmdyck! I've gone ahead with your "forward" suggestion. |
|
Yup, this looks good to go now. |
…9#1725) - Add "Value Notation" section. - Fix Element Type inconsistencies.
ljharb
force-pushed
the
use-tildes-where-possible
branch
from
ad7ce87 to
ce66e8f
Compare
When extracting an 'Element Size' from the TypedArray Constructors table, we have two syntaxes: - `the Element Size ... for _foo_` - `the Element Size ... for Element Type _foo_` With the first, _foo_ is the name of a constructor from column 1 of the table. With the second, _foo_ is an element type from column 2 of the table. However, there's one line that uses the first syntax, but with the second semantics. This commit changes it to use the second syntax. (This bug/inconsistency goes back to ES6, and was brought to light by the changes from PR tc39#1725.)
When extracting an 'Element Size' from the TypedArray Constructors table, we have two syntaxes: - `the Element Size ... for _foo_` - `the Element Size ... for Element Type _foo_` With the first, _foo_ is the name of a constructor from column 1 of the table. With the second, _foo_ is an element type from column 2 of the table. However, there's one line that uses the first syntax, but with the second semantics. This commit changes it to use the second syntax. (This bug/inconsistency goes back to ES6, and was brought to light by the changes from tc39#1725)
3 participants
Follow-up to #1302, prerequisite for the
`"foo"`→*"foo"*update.This patch aims to change all non-observable magic strings into
~foo~-style spec-internal values.