Object.seal, read references, and code reliability

Tue Aug 15 05:41:35 UTC 2017

Your points are goods ones. However, I believe .toString and .valueOf are on the Object prototype so should not be a problem. .then is on the Promise object prototype so also not a problem.

The well-known Symbols are indeed an issue. My inclination would be to exempt Symbols from Object.guard exceptions as their whole point is feature detection (wonder why toJSON didn't use a symbol?). The point of Object.guard is to catch extremely common screw-ups, AKA, typos or misunderstandings such as using foo.longlist when it should be foo.longList (or 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: Jordan Harband [mailto:ljharb at gmail.com]
Sent: Tuesday, August 15, 2017 12:02 AM
To: Alex Kodat <akodat at rocketsoftware.com>
Cc: don at sencha.com; es-discuss at mozilla.org
Subject: Re: Object.seal, read references, and code reliability

Don't forget besides `.toJSON`, all the other methods that builtins do a [[Get]] on: `.toString`, `.valueOf`, `.then`, and all the well-known symbols (Symbol.iterator, Symbol.isConcatSpreadable, etc) - and in node, `.inspect` in the repl.

You're totally right that Proxy, and ES5 getters before that, makes "accessing a property" always be something that can throw - just pointing out that there's a *lot* of places that `[[Get]]`s happen in the language.

On Mon, Aug 14, 2017 at 9:57 PM, Alex Kodat <mailto:akodat at rocketsoftware.com> wrote:
On Mon Aug 14 18:49:35 UTC 2017 Don Griffin wrote
------------------------------------------------------------------------------------
<imho>Land mines like this are bad for JS. Reads should always be safe to do as in "foo && foo.bar". Throwing errors from that is always bad. duck-typing, feature detection etc are all valid uses for objects ... even sealed/frozen/locked/obfuscated ones :) </imho>

Just give me "undefined" on reads like these. I would much rather have that and possibly Object.isFrozen/isLocked/isSealed etc methods to test these conditions if appropriate.
------------------------------------------------------------------------------------
No one would force anyone to use Object.guard (what I initially called Object.lock). It would introduce no backward incompatibilities.

Whatever landmines this feature would introduce have been there at least since proxies were introduced since, with proxies, a get for a non-existent property might throw. In fact, even with a simple property getter you can get an exception from a getter. So the good old days when reads were always safe was a very long time ago. Of course, in your own code, you can very easily make your reads always safe and I'd say more power to you.

Duck-typing, feature detection, etc. can be wonderful things but so can objects with a well-defined set of properties. And in the latter case, it makes debugging much easier and faster if references to non-existent properties throw an exception.

Even in the face of Object.guard, feature detection could be done with Object.getOwnPropertyNames and Object.getPrototypeOf or Object.prototype.hasOwnProperty (the latter if one doesn't care about properties in prototype classes). In fact, as a general rule doing a feature test as if (foo.feature) is kinda sketchy as, of course, if foo.feature were 0 or "" or false your test would suggest a missing feature. Even if foo.feature returned undefined you don't know whether the property's explicitly set to undefined or simply not there (shame on you if there's a difference?).

Your e-mail does point to one minor fly in the ointment for the proposed Object.guard function, specifically the toJSON function for which a [[Get]] will be performed for every object being JSON.stringify'ed. This means that every object that is Object.guard'ed would require a toJSON in its prototype chain. A little annoying but a price to pay, I guess for using Object.guard. One would probably need to do the same for inspect. Of course one can set toJSON and inspect to undefined on the base Object prototype but that would probably be pretty uncool for most JavaScript engines.  There'd be other ways around this such as redefining JSON.stringify's use of toJSON to check for presence of the toJSON property before doing a [[Get]]. This would be indistinguishable from current behavior. And though it might seem expensive, I suspect most of the time there will be no toJSON property for most objects so the test for the property existence would be all that would be done.

------
Alex Kodat
Senior Product Architect
Rocket Software
t: tel:%2B1%20781%20684%202294 • m: tel:%2B1%20315%20527%204764 • w: http://www.rocketsoftware.com

================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: tel:%2B1%20877.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.