How would an implementation optimize object allocation here?

[dead-claudia]

It'd be very inefficient for an object to simply delegate to the weak map on each reference access, so I'm curious how an implementation might choose to elide that with the help of inline caches.

My initial idea is this:

• For maps, you'd have to delegate. Otherwise, you're duplicating memory without reason.
• For weak maps, if the value is not exposed or used elsewhere, an implementation might choose to drop some ICs guarding each access and set the values in a separate set of key/value fields where the keys are the weak maps themselves. As part of the object's ICs, it could add those weak map-backed fields to its type map, and it could use those to generate the relevant offsets for the objects. If they're set in some sort of constructor (even if it's a factory), it might choose to pre-allocate those fields initially, so it doesn't have to re-add them later.

[zenparsing]

That sounds reasonable.

An implementation can notice that the WeakMap representing the private data will outlive all of the instances of the class with which it is associated, and simply store the private data with the object itself.

Of course, the @@referenceGet and @@referenceSet methods could be overridden so an engine will have to protect against those scenarios, but that's just how JavaScript works.

[dead-claudia]

I just wanted to establish whether it'd create optimization issues first before lending my support to it. I'd rather not have slow private slots, and I know implementations would be hesitant to implement something like this that they can't optimize away in a common case, especially when it's not really solving very many problems. My curiosity is whether it's possible for a map to do something similar, just using a set internally for objects with slots:

• The map would build the set so it could still enumerate and clear the relevant properties from the objects on Map.prototype.clear.
• The map would have to bail out of the fast path of a weak map-like implementation if any numbers or other primitives are added, and they'd have to rehash the entries into a new reified map and remove their internal slots from the objects. Lazy IC patches would have to also be queued up for their entries' type maps so inlined reference accesses can have their offsets updated before continuing.
• This bailout would be expensive and complicated enough that it might offset the gains you'd otherwise get from just using a weak map (which can't be iterated).

But as it stands, I kind of like your proposal here. It's not far off of mine, just it's a bit more dynamic. It even permits easy privacy control, without having to concern yourself about super/etc.