Bob Myers (2017-08-15T05:39:59.000Z)
> That's not a feature JavaScript has - you might be thinking of
alternative languages, which are not JavaScript.

Yes, I know. JavaScript doesn't have `lock` either, yet here we are talking
about it.

The OP is concerned about accesses to unknown or undefined properties. As I
understand it, he proposes mechanisms to throw errors on attempts to make
such accesses.

The astronauts in the Mars lander would certainly not be happy with a
solution involving the landing app crashing when it encountered some rare
code path which accessed an unknown property on an object. I'm sure they'd
prefer a compile-time error to be generated safely back on earth during the
development process, long before the code shipped.

What I am saying is that as far as I can tell the OP's notion of locking is
an attempt to add a feature to the language which amounts to enforcing type
constraints at run-time. In my humble opinion, type constraints should be
enforced during a type-checking phase, based on type assertions,
annotations, declarations, inferences, and definitions. Yes, I know JS does
not have those now. I hope it does sometime in the future. If it never
does, then I don't think we should try to enforce them on a piece-meal
basis via run-time checks and special locked statuses.

Bob

On Tue, Aug 15, 2017 at 10:55 AM, Jordan Harband <ljharb at gmail.com> wrote:

> 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/20170815/a7bd0dbb/attachment-0001.html>
rtm at gol.com (2017-08-15T06:57:09.725Z)
> That's not a feature JavaScript has - you might be thinking of alternative languages, which are not JavaScript.

Yes, I know. JavaScript doesn't have `lock` either, yet here we are talking
about it.

The OP is concerned about accesses to unknown or undefined properties. As I
understand it, he proposes mechanisms to throw errors on attempts to make
such accesses.

The astronauts in the Mars lander would certainly not be happy with a
solution involving the landing app crashing when it encountered some rare
code path which accessed an unknown property on an object. I'm sure they'd
prefer a compile-time error to be generated safely back on earth during the
development process, long before the code shipped.

What I am saying is that as far as I can tell the OP's notion of locking is
an attempt to add a feature to the language which amounts to enforcing type
constraints at run-time. In my humble opinion, type constraints should be
enforced during a type-checking phase, based on type assertions,
annotations, declarations, inferences, and definitions. Yes, I know JS does
not have those now. I hope it does sometime in the future. If it never
does, then I don't think we should try to enforce them on a piece-meal
basis via run-time checks and special locked statuses.

Bob