Object.seal, read references, and code reliability

Tue Aug 15 05:49:48 UTC 2017

 - Every non-null/undefined value is checked for "then" when it's passed to
a Promise's resolver, not just promises.

 - Every non-null/undefined value, including `Object.create(null)` or `new
(class extends null {})`, has valueOf and/or toString checked when
attempting to convert it to a primitive.

 - toJSON was added in 2009/2011; Symbols were added in 2015.

On Mon, Aug 14, 2017 at 10:41 PM, Alex Kodat <akodat at rocketsoftware.com>
wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170814/4f06e4ad/attachment-0001.html>