Object.seal, read references, and code reliability

T.J. Crowder tj.crowder at farsightsoftware.com
Tue Aug 15 17:52:20 UTC 2017

My mind's been completely changed on this by the arguments from various

It seems to me that `Object.seal` and `Object.freeze` have a *runtime*
purpose: Protecting your objects from extension when passed to foreign
code. It's great you're also getting value out of it *within* your code
base, but I don't see that as the primary motivation of them.

Whereas this guard concept is (almost?) entirely a "catch the bug early"
feature, which it seems to me is more in the realm of linting,
TypeScript-style compilation, and (as Jordan mentioned) testing.

Adopting something like TypeScript is indeed a non-trivial change not just
to your build process but primarily to your working methods. It would have
costs and benefits. Your team will have to weigh the inevitable costs ("How
the heck do I tell TypeScript _____?!") against the benefits of catching
these kinds of problems at the point of authoring (with IDE support) or
compiling the code, far earlier than you would have relying on a runtime

My main point being: There's a clear runtime purpose to what we have. I'm
not seeing the *runtime* purpose for this guard idea. Is it a failure of
imagination on my part?

-- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170815/2364fa18/attachment.html>

More information about the es-discuss mailing list