Re: [heycam/webidl] Standardize around typography of IDL true/false/null (#457)

tobie requested changes on this pull request.

So cleaning the incorrectly marked-up non-ES values is great. Thanks a lot! However, I think we should strive to be consistent with how the ES spec marks-up ES and keep ES booleans, numbers, etc. within `<emu-val>` tags, as the ES spec does.

> @@ -11718,7 +11721,7 @@ then the [=function object=] is {{%ArrayProto_keys%}}.
     1.  Return |iterator|.
 </div>
 
-The value of the [=function object=]’s “length” property is the Number value <emu-val>0</emu-val>.

Curious why we're removing emu-val here.

> @@ -11852,7 +11855,7 @@ must be {{%IteratorPrototype%}}.
                 1.  Call <a abstract-op>CreateDataProperty</a>(|array|, "1", |value|).
                 1.  |result| is |array|.
         </dl>
-    1.  Return <a abstract-op>CreateIterResultObject</a>(|result|, <emu-val>false</emu-val>).

Does ES make a distinction between ES booleans and abstract booleans in abstract ops?

> @@ -12109,7 +12112,7 @@ These additional properties are described in the sub-sections below.
         the value of |O|’s \[[BackingSet]] [=internal slot=].
     1.  Let |function| be the result of calling the \[[Get]] internal method of |set|
         passing |name| and |set| as arguments.
-    1.  If <a abstract-op>IsCallable</a>(|function|) is <emu-val>false</emu-val>,

Similar question here. Are the values returned by abstract ops *not* ES booleans?

>  *   ECMAScript language types: Object
+*   ECMAScript values: generally the same notation as IDL values; bolded type (e.g.

I'm not sure we have the same perspective, here. I feel like ES values should be clearly marked as such across the spec, as they are in the ES spec.

> @@ -11434,9 +11437,9 @@ then there must exist a property with the following characteristics:
     then the property exists on every object that implements the interface.
     Otherwise, the property exists on the [=interface prototype object=].
 *   The property has attributes
-    { \[[Writable]]: |B|, \[[Enumerable]]: <emu-val>true</emu-val>, \[[Configurable]]: |B| },
-    where |B| is <emu-val>false</emu-val> if the stringifier is [=unforgeable=] on the interface,
-    and <emu-val>true</emu-val> otherwise.
+    { \[[Writable]]: |B|, \[[Enumerable]]: true, \[[Configurable]]: |B| },

I'd rather we stayed consistent with the ES spec, which marks-up ES values within property descriptors.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/457#pullrequestreview-69822751