Object.seal, read references, and code reliability

[Jordan Harband]

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 <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: +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.
> _______________________________________________
> 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/c737c9b0/attachment.html>