Object.seal, read references, and code reliability

[T.J. Crowder]

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

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

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>