Internal slots vs. instance get/set methods

[js-choi]

I haven’t seen this discussed explicitly, so I’m wondering if it has been addressed.

In the specification, Map.prototype.emplace currently retrieves and sets values directly from the this-value’s [[MapData]] internal slot.

What are the advantages and disadvantages of emplace using the [[MapData]] internal slot – versus calling the this-value’s get and set methods?

(This came up because, in tc39/proposal-policy-map-set#11, we’re discussing possibly subclassing CacheMap. Furthermore, CacheMap itself might be a subclass of Map; see tc39/proposal-policy-map-set#1. If we subclass CacheMap and override its get and set methods, then emplace’s default implementation should use instance get/set methods, or else emplace will always have to be overridden too. However, if Map.prototype.emplace uses internal slots, then that necessitates a different approach.)

[ljharb]

It's more robust and less observable, which is good on its own, but may also lead to more opportunity for optimization.

Subclasses that override base class methods simply have to override every method, which is why "overriding base class methods" is a poor choice for subclassing.

[conartist6]

I foresee some problems with internal slots: #51

[michaelficarra]

The precedent-setting decision from the Set methods proposal was to use internal slots directly when operating on the this value and method calls when operating on values passed in the arguments list.

/cc @bakkot