Object.seal, read references, and code reliability

[Bob Myers]

> by immediately pointing out the error.

This does **not** "immediately point out the error". It would "point out
the error" (by raising an exception) only f and when the code path
involving the mistyped property name were actually followed. The thrown
error might be swallowed in some contexts, or disappear into the ether in a
production environment, or cause a server to crash.

We have had tools for immediately pointing out such errors for more than
half a century. They are called "compilers".

> with (almost?) no cost,

I will go out on a limb here and predict that the community would be
unlikely to accept any alternative which adds a nanosecond of cost.

Bob


On Tue, Aug 15, 2017 at 7:34 PM, Alex Kodat <akodat at rocketsoftware.com>
wrote:

> Yup, I kinda liked strong mode but the good news/bad news was that you got
> a lot of behaviors in a single package which was convenient but also
> problematic if any of the behaviors proved inappropriate for a context.
>
>
>
> IMO, improving code reliability is trench warfare where progress is
> usually measured in inches and while I think Object.guard is a useful tool
> I’m under no illusions that it’s a game-changer (any more than Object.seal,
> say). But there are a large number of cases where when a programmer
> mistakenly types foo.bah as opposed to foo.bar it is inarguably a mistake
> and you’re doing the programmer a favor by immediately pointing out the
> error.  So if we could catch these cases relatively easily with (almost?)
> no cost, why not?
>
>
>
> I’ll concede that there are issues here that I and others have brought up
> that suggest that Object.guard is not quite as simple as Object.seal but I
> believe these issues are not so daunting as to disqualify the feature. But
> reasonable people could disagree.
>
>
>
> As far as performance goes, I don’t see how Object.guard could possibly
> improve performance. That’s not its purpose.
>
>
>
> ------
>
> Alex Kodat
> Senior Product Architect
> Rocket Software
> t: +1 781 684 2294 • m: +1 315 527 4764 • w: www.rocketsoftware.com
>
>
>
> *From:* Isiah Meadows [mailto:isiahmeadows at gmail.com]
> *Sent:* Tuesday, August 15, 2017 12:57 AM
> *To:* Alex Kodat <akodat at rocketsoftware.com>; Jordan Harband <
> ljharb at gmail.com>
> *Cc:* es-discuss at mozilla.org
> *Subject:* Re: Object.seal, read references, and code reliability
>
>
>
> Just a quick note: Look up "strong mode", an experiment by Google
> attempting to look for code quality improvement and perf gains for locking
> class instances by default. I feel it's pretty relevant here, and here's a
> quick summary of their general findings:
>
>
>
> 1. It helped code quality only *a little* (stuff better code design could
> solve better)
>
> 2. It had very little gain in performance
>
> ================================
> 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/20170815/7c3cd76b/attachment.html>