Object.seal, read references, and code reliability
Alex Kodat
akodat at rocketsoftware.com
Tue Aug 15 05:02:35 UTC 2017
It's not a compile-time check because a compile-time check is impossible:
function noname(foo) {
let abc = foo.abc;
}
How could the compiler possibly know whether abc exists on foo?
------
Alex Kodat
Senior Product Architect
Rocket Software
t: +1 781 684 2294 • m: +1 315 527 4764 • w: http://www.rocketsoftware.com/
From: Bob Myers [mailto:rtm at gol.com]
Sent: Monday, August 14, 2017 11:55 PM
To: Alex Kodat <akodat at rocketsoftware.com>
Cc: Jerry Schulteis <jdschulteis at acm.org>; es-discuss at mozilla.org
Subject: Re: RE: Object.seal, read references, and code reliability
Is there some reason this is not just a compile-time type check?
Bob
On Tue, Aug 15, 2017 at 4:16 AM, Alex Kodat <mailto:akodat at rocketsoftware.com> wrote:
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: http://www.rocketsoftware.com/
From: Jerry Schulteis [mailto:mailto:jdschulteis at yahoo.com]
Sent: Monday, August 14, 2017 5:21 PM
To: Alex Kodat <mailto:akodat at rocketsoftware.com>
Cc: mailto: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 <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
a. Let readStrict be ? O.IsReadStrict(Receiver) || ReadStrict
b. Let parent be ? O.[[GetPrototypeOf]]().
c. If parent is null then
i. Assert: readStrict is false
ii. return undefined.
d. Return ? parent.[[Get]](P, Receiver, readStrict).
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).
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: 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 <mailto:akodat at rocketsoftware.com>
Cc: 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 <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
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.
_______________________________________________
es-discuss mailing list
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.
More information about the es-discuss
mailing list