Object.seal, read references, and code reliability

[T.J. Crowder]

On Mon, Aug 14, 2017 at 5:32 PM, Alex Kodat <akodat at rocketsoftware.com>
wrote:
> Is there any reason that there’s no flavor of Object.seal that
> would throw an exception on read references to properties that are
> not found on the specified object?

This sounds like a good idea at a high level. Will be very interested to
know what implementers have to say about it from an implementation
perspective.

In spec terms, at first glance it's mostly just a new pair of steps in
[OrdinaryGet ordinary object internal function][1] (added Step 3.a and 3.b):

```text
1. Assert: IsPropertyKey(P) is true.
2. Let desc be ? O.[[GetOwnProperty]](P).
3. If desc is undefined, then
 a. Let readExtendable be ? IsReadExtensible(Receiver).
 b. If readExtendable is false, throw TypeError.
 c. Let parent be ? O.[[GetPrototypeOf]]().
 d. If parent is null, return undefined.
 e. Return ? parent.[[Get]](P, Receiver).
4. If IsDataDescriptor(desc) is true, return desc.[[Value]].
5. Assert: IsAccessorDescriptor(desc) is true.
6. Let getter be desc.[[Get]].
7. If getter is undefined, return undefined.
8. Return ? Call(getter, Receiver).
```

...where `IsReadExtensible` is an op to test the new flag. *(Used `pre`
markdown to avoid the `[[...](.)` being treated as links without having to
add `\` for those not reading the rendered version.)*

One concern is people already have trouble keeping sealed and frozen
straight (or is that just me?). Adding a locked (or whatever) makes that
even more confusing. But the semantics of sealed and frozen can't be
changed to include this now.

-- T.J. Crowder

[1]: https://tc39.github.io/ecma262/#sec-ordinaryget
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170814/31e0301b/attachment.html>