Object.seal, read references, and code reliability

Tue Aug 15 05:25:37 UTC 2017

That's not a feature JavaScript has - you might be thinking of alternative
languages, which are not JavaScript.

On Mon, Aug 14, 2017 at 10:21 PM, Bob Myers <rtm at gol.com> wrote:

> > How could the compiler possibly know whether abc exists on foo?
>
> Sorry for not being clearer.
> It would know by means of appropriate type declarations/assertions.
>
> Bob
>
> On Tue, Aug 15, 2017 at 10:32 AM, Alex Kodat <akodat at rocketsoftware.com>
> wrote:
>
>> 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 <(781)%20684-2294> • m: +1 315 527 4764
>> <(315)%20527-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 <(781)%20684-2294> • m: +1 315 527 4764
>> <(315)%20527-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 <(781)%20684-2294> • m: +1 315 527 4764
>> <(315)%20527-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 <(877)%20328-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 <(877)%20328-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 <(877)%20328-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/20170814/b6e2bce0/attachment-0001.html>