Object.seal, read references, and code reliability

Mon Aug 14 22:46:39 UTC 2017

Agree, lock’s not a good name. That was just a dumb name because I was too lazy to think of something better. Other names that come to mind (some also with other software connotations):

Object.box
Object.protect
Object.close
Object.guard
Object.fence
Object.shield

But don’t care that much and probably someone could come up with better. I guess of the above I like Object.guard. So I’ll use that for now…

Also, I’ll retract an earlier stupid statement I made where I suggested that if a property referenced an accessor descriptor without a getter it should throw if the guard bit is set. This is obviously wrong. As long as the property name is present, not having a getter is equivalent to the property being explicitly set to undefined which should not throw. That is:

let foo = Object.guard({a: 1, b: undefined});
console.log(foo.b);

should not throw.

Also, FWIW, I had originally thought of Object.guard as Object.seal on steroids but some thought makes me realize it’s really orthogonal and can picture cases where one might want to seal an object but not guard it and vice versa.

------
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: Jerry Schulteis [mailto:jdschulteis at yahoo.com]
Sent: Monday, August 14, 2017 5:21 PM
To: Alex Kodat <akodat at rocketsoftware.com>
Cc: es-discuss at mozilla.org
Subject: Re: RE: Object.seal, read references, and code reliability

I'm ok with the basic idea. I don't think "lock" is a good name for it. Nothing about "Object.lock(myObj)" suggests that future access to a non-existent property of myObj will throw. Also "lock" carries a well-established, unrelated meaning in computer science.

Could this be done with an additional argument to Object.seal(), Object.freeze(), and Object.preventExtensions()?
Like so: "Object.seal(myObj, Object.THROW_ON_ABSENT_PROPERTY_READ)"--wordy, but the intent is unmistakable.
On Monday, August 14, 2017, 1:16:39 PM CDT, Alex Kodat <akodat at rocketsoftware.com<mailto:akodat at rocketsoftware.com>> wrote:

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<mailto:akodat at rocketsoftware.com>>
Cc: es-discuss at mozilla.org<mailto: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):

```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

================================
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.
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss

================================
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/2ee1954f/attachment-0001.html>