Object.seal, read references, and code reliability

Alex Kodat akodat at rocketsoftware.com
Mon Aug 14 18:16:28 UTC 2017

FWIW, I’m not sure I agree with your OrdinaryGet steps. Also, not sure I like readExtensible as it doesn’t really have anything to do with extensibility. Maybe readStrict? But maybe I’m thinking about extensibility wrong?

In any case, I think the description of [[Get]] would have to be like (sorry, I’ve never done this sort of spec pseudo code so some of this is probably syntactically incorrect):

[[Get]] (P, Receiver, ReadStrict)

  1.  Return ? OrdinaryGet(O, P, Receiver, ReadStrict).

And OrdinaryGet would be like:

OrdinaryGet (O, P, Receiver, ReadStrict)#

  1.  Assert: IsPropertyKey(P) is true.
  2.  Let desc be ? O.[[GetOwnProperty]](P).
  3.  If desc is undefined, then

  1.  Let readStrict be ? O.IsReadStrict(Receiver) || ReadStrict
  2.  Let parent be ? O.[[GetPrototypeOf]]().
  3.  If parent is null then

i.                     Assert: readStrict is false

ii.                    return undefined.

  1.  Return ? parent.[[Get]](P, Receiver, readStrict).

  1.  If IsDataDescriptor(desc) is true, return desc.[[Value]].
  2.  Assert: IsAccessorDescriptor(desc) is true.
  3.  Let getter be desc.[[Get]].
  4.  If getter is undefined, return undefined.
  5.  Return ? Call(getter, Receiver).

Probably adjustments need to be made to other references to [[Get]] and OrdinaryGet, passing false for ReadStrict.

I guess this pseudo code also points out an issue as to whether Object.lock would affect a dynamic property with no getter. Intuitively, it seems to me that it should.

Alex Kodat
Senior Product Architect
Rocket Software
t: +1 781 684 2294 • m: +1 315 527 4764 • w: www.rocketsoftware.com<http://www.rocketsoftware.com/>

From: T.J. Crowder [mailto:tj.crowder at farsightsoftware.com]
Sent: Monday, August 14, 2017 12:00 PM
To: Alex Kodat <akodat at rocketsoftware.com>
Cc: es-discuss at mozilla.org
Subject: Re: Object.seal, read references, and code reliability

On Mon, Aug 14, 2017 at 5:32 PM, Alex Kodat <akodat at rocketsoftware.com<mailto: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):

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 877.328.2932
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170814/9eaabafa/attachment-0001.html>

More information about the es-discuss mailing list