Object.seal, read references, and code reliability

Bob Myers rtm at gol.com
Tue Aug 15 04:54:40 UTC 2017


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 <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: 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> 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
>
>
>
> *From:* T.J. Crowder [mailto:tj.crowder at farsightsoftware.com
> <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>
> 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
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170815/fbbf756f/attachment-0001.html>


More information about the es-discuss mailing list