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