Object.seal, read references, and code reliability

[Alex Kodat]

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: +1 781 684 2294 • m: +1 315 527 4764 • w: www.rocketsoftware.com

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