change "harden" to share a WeakMap of already-frozen objects about endo HOT 6 CLOSED

No, because Object.isFrozen is not transitive. If def stopped at a frozen object, it could miss non-frozen objects that were reachable from named properties of that frozen object:

const bad = Object.freeze([{}]);
// At this point, we have a frozen array containing 
// a non-frozen object in its transitive API surface.
def(bad);

If the call to def succeeds, then the transitive API surface starting at bad must be frozen. But an isFrozen check would stop too early.

from endo.

Noting again here that we're likely to change terminology from "deeply frozen" and such to "hardened".

from endo.

can you use Object.isFrozen(obj)

from endo.

In addition to labeling this an "enhancement" I also label it a "bug" because it is a huge performance bug. Normally, if there is no deviation from correct overt behavior I avoid "bug". But the performance shortfall here is huge.

from endo.

This weakmap seems to be global mutable state. Why is that ok in this case?

Also, is it shared between realms? Between calls to require('harden')?

from endo.

This weakmap seems to be global mutable state. Why is that ok in this case?

Also, is it shared between realms? Between calls to require('harden')?

I'm going to open a separate issue to discuss this, I think we have an answer but I don't want to lose visibility when I close this as fixed in a few minutes.

from endo.