Object.seal, read references, and code reliability

[Alex Kodat]

If you want to protect your objects from the ravages of the unwashed masses, the best way is with closures. Object.seal doesn’t really buy you a heck of a lot of protection as while, sure, it prevents someone from adding new properties to your objects it doesn’t prevent them from messing with your existing properties which seems a lot worse. Plus, even if they don’t mess with them,  they can see them and build dependencies on implementation details (the Node.js ecosystem  has plenty of this) that make it difficult to change things intended for internal use only. If you’re worried about this, use closures (or Symbol properties or weak maps though I think closures are generally superior). 

So maybe it’s my failure of imagination but I view Object.seal as a tool for catching typos in assignments and for enforcing a coding standard where all properties must be added “up front”. At least in V8, defining all properties up front minimizes the number of (internal C++) Maps and helps the optimizer out and seal simply prevents people from messing this up by deleting a property but performance seems an esoteric worry when consumers are deleting object properties.

Object.freeze I guess lets you expose an object that you know should not change but on whose contents your code depends. I guess this comes up in applications but all the uses of Object.freeze I've come across are in internal code -- I know some object should not change after some event so I freeze it to catch any mistaken attempts to change it. Again, trapping errors, not providing encapsulation. Even when the object's frozen, I don't want to expose it outside my code as this can paint me in a corner.

I certainly have a hard time picturing Object.seal or Object.freeze as encapsulation aids which is what I understand when I read "protecting your objects". So, at least from my point of view, Object.guard would be a tool in the same problem space as Object.seal and to a somewhat lesser degree Object.freeze. I'll freely admit, Object.seal is a more powerful tool than Object.guard for my purposes as it allows enforcement (more or less) of certain coding standards. But I'd still love to have Object.guard.

From: T.J. Crowder [mailto:tj.crowder at farsightsoftware.com] 
Sent: Tuesday, August 15, 2017 12:52 PM
To: Alex Kodat <alexkodat at gmail.com>
Cc: Jordan Harband <ljharb at gmail.com>; es-discuss at mozilla.org
Subject: Re: Object.seal, read references, and code reliability

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