Return values of mutating MOP operations (Was: response chapter 8 except 8.5 (was Re: ES6 Rev13 Review: MOP-refactoring, symbols, proxies, Reflect module))

Tom Van Cutsem tomvc.be at gmail.com
Mon Dec 31 04:27:45 PST 2012


2012/12/31 Allen Wirfs-Brock <allen at wirfs-brock.com>

> 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:
> > 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.
>

Three reasons:
1) As you say, consistency with [[DefineOwnProperty]], [[Delete]] and
[[Set]] (maybe also [[SetInheritance]]). Every operation that mutates an
object returns a success code indicating whether or not the intended change
took place.

2) Before proxies and symbols, [[PreventExtensions]] could never fail. With
the advent of new exotics, this operation may be "rejected". Proxies and
symbols need a way to signal this. Essentially Object.preventExtensions
should throw a TypeError when [[PreventExtensions]] return false.
Object.preventExtensions should never fail silently on a proxy that rejects
the operation.

3) It would be really useful if Reflect.preventExtensions returned the
boolean success code, as this provides an easier way to test if this
operation succeeded than is possible with Object.preventExtensions. Compare:

if (Reflect.preventExtensions(obj)) { /* success code */ } else { /*
failure code */ }

vs.

try {
  Object.preventExtensions(obj);
  /* success code */
} catch (e) { if (!(e instanceof TypeError)) throw e; // not even a
fool-proof test
  /* failure code */
}


> >   * [[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?
>

The success code for [[Delete]] is indeed fuzzy as it may mean:
a) the property was/was not successfully deleted
b) the property is / is no longer present

Since deleting a non-existent property returns true, b) is closer to the
existing semantics.

Here's my alternative wording:
[[Delete]] (propertyKey) -> Boolean: "Removes the own property indentified
by the propertyKey parameter from the object. Return false if the property
was not deleted and is still present. Return true if the property was
deleted or was not present."

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121231/f65c5614/attachment-0001.html>


More information about the es-discuss mailing list