response chapter 8 except 8.5 (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module)

Allen Wirfs-Brock allen at wirfs-brock.com
Sun Dec 30 15:24:54 PST 2012


responses for chapter 8, except for 8.5 which will get its own message.


On Dec 29, 2012, at 2:37 PM, Tom Van Cutsem wrote:

> ...
> === Chapter 8 ===
> 
> 8.1.6.2
> "Unless explicitly specified otherwise, internal data properties may be dynamically added to ECMAScript objects."
> Isn't it safer to err on the side of safety and specify the opposite? (i.e. "properties cannot be dynamically added unless specified otherwise")?

This was important for allowing"subclassing" of built-ins before we came of with the @@create refactoring of [[Construct]].  I now may not be necessary.   Currently (including legacy pseudo code from ES and ES5) we have algorithms that are expressed as if some internal data properties are added after object creation.  By the time we are done, perhaps that too will go away. 

Originally, the expectation was that the dynamic requirement could be meet by using an implementation secret private symbol as a property key...


(note, that after I released rev 13 noticed I didn't update Table 8 to reflect changes from rev 12 to rev 13.  that's been taken care of)
> 
> Table 8:
>   * [[PreventExtensions]] internal method: should return a Boolean success value

Why?  no caller of [[PreventExtension]] currently uses such a result.  In general, we did try to make more of the internal methods return true/false success indicators rather than deeply burying the decision of whether or not an exception should be generated on failure.  Do you have something in mind where a caller of [[PreventExtension]] within the spec. (or a caller of Reflect.preventExtensions) needs a true/false success code?  Or maybe we should just do it for consistency sake.

>   * [[Delete]]: I would remove "because its [[Configurable]] attribute is false." from the description. Proxies and host objects may return false for other reasons as well (cf. the recent discussions about DontDelete vs. configurable:false)

Do you have some alternative wording?  These descriptions (along with whatever eventually goes into 8.1.6.3)  are intended to be the informal description of the contract of these MOP methods.  What is true or false actually intended to mean for [[Delete]]?  Is it that false means:  the property exists but the property wasn't deleted?


>   * [[Enumerate]]: typo: "Returns an iterator object that {iterates} over the string values"
fixed
>   * [[Keys]] should be removed
>   * [[HasProperty]] should probably be added to this table again
yes, already fixed
>   * [[OwnPropertyKeys]]: the return type should be changed to Object (iterator)

we don't currently have a notation of qualifying the Object type in these signatures. So, the description generally is used to do the qualification.  The notation could be fixed, it doesn't seem like a high priority currently.
> 
> 
> 8.3.4 Object [[PreventExtensions]]()
> This method should return a Boolean (true).

see above
> 
> 8.3.7.3 ValidateAndApplyPropertyDescriptor
> Typo: "… and no{t} object updates are {pre}formed"
fixed
> 
> The note: "However, if O has an [[BuiltinBrand]] internal data property whose value is BuiltinArray O also has a more elaborate [[DefineOwnProperty]] internal method defined in 15.4.5.1." is probably more appropriately placed at the top of section 8.3.7 (closer to the definition of [[DefineOwnProperty]])

It's actually not a note, but rather a normative statement.  Regardless, it and similar statements are left-overs from before the destination between ordinary and exotic objects was clearly defined.  I think I'm just going to get rid of all such statements.

> 
> The note: "NOTE Step 10.b allows any field…" should probably refer to Step 10.a (there is no longer a step 10.b in the new ValidateAndApplyPropertyDescriptor algorithm)
> 
fixed, it's actually 8.b

> 
> 8.7.8 Object [[HasProperty]] ( P )
> - The section number should probably be 8.3.8
fixed
> "When the [[GetProperty]] internal method" => should probably be [[HasProperty]].
fixed
> 
> 
> 8.3.19 Ordinary Function Objects
> Table 13: Description for [[Home]]
> "…this is the object whose [[Inheritance]] provides the object…"
> should probably be [[GetInheritance]].
fixed
> 
> 
> 8.4 Built-in Exotic Object Internal Methods and Data Fields
> 
> A few typos in introductory text:
> "This specification define{s} several kinds of built-in exotic objects.  These objects generally behave similar to ordinary objects except for a few specific situ{t}ations.  The following exotic objects use the ordinary object internal methods except where it is explicitly specified {other}wise below:"
fixed
> 
> 8.4.4 Exotic Symbol Objects
> Typo: "A{n} Symbol object is an exotic object…"
> "Exotic String objects have {the} a..."
fixed
> 
> In the introduction, it's mentioned that "Symbol exotic objects are unique in that they are always immutable and never observably reference any other object."
> 
> Yet, as currently specified, evaluating aSymbol.toString yields a reference to the global Object.prototype.toString function (which is mutable by default).
I agree, that the statement does not quit match the apparent behavior.  Yet, the definition of [[GetP]] for Symbols makes it clear that the symbol itself does not reference the toString method and instead it is using the toString intrinsic of the Realm associated with the execution context that did the [[GetP]] access.

I'll think about how to express the key idea (symbols directly carry no object references) while still supporting toString

> 
> Shouldn't aSymbol.toString just be undefined?
> 
> I notice that Object.prototype.toString special-cases Symbols anyway, so Object.prototype.toString.call(aSymbol) continues to work fine.
> 

I think, for debugging, people will prefer to obj.toString() to yield "[object Symbol]" rather than throwing when obj happens to be a symbol.

> In case aSymbol.toString should continue to return Object.prototype.toString, I would advise to modify [[HasProperty]] for Symbols to answer 'true' for the string "toString", and [[Delete]] to answer 'false', so that [[Get]],[[HasProperty]] and [[Delete]] remain internally consistent.

I'm not so sure.  DHerman and I had a recent conversation about a related matter, and its not clear that it always makes sense to make [[GetP]] and [[GetOwnProperty]] consistent.  In this case, note that [[GetOwnProperty]] would be required to report that toString was writable, because its value observably changes based upon the Realm from which it is accessed.

In this case, it may be better to have this be a little hack that supports debugging and not worry about all the other small inconsistencies that are not really guaranteed invariants, regardless.

> 
> 8.4.5 Exotic Arguments Objects
> Typo: "They also have a [[Par{a}meterMap]] internal data property"

fixed, and of course a bunch of code needs to move here.
> 



More information about the es-discuss mailing list