Object.seal, read references, and code reliability
tj.crowder at farsightsoftware.com
Mon Aug 14 16:59:34 UTC 2017
On Mon, Aug 14, 2017 at 5:32 PM, Alex Kodat <akodat at rocketsoftware.com>
> 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
In spec terms, at first glance it's mostly just a new pair of steps in
[OrdinaryGet ordinary object internal function] (added Step 3.a and 3.b):
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss