Extra work/more complicated example in "Maintaining a counter"

[LinusU]

The current example "Maintaining a counter" seems to be extra convoluted in order to use the new method. I think that this might be a remnant from earlier iterations of the proposal. Right now the code is:

let counts = new Map();
counts.set(key, counts.getOrInsert(key, 0) + 1);

but this code is functionally equivalent, and avoids first inserting 0 only to immediately replace it with 1:

let counts = new Map();
counts.set(key, (counts.get(key) ?? 0) + 1);

It's also shorter.

[ljharb]

It's not entirely equivalent for a generic Map instance (which could be a subclass) - it calls get but not has. I'd think the equivalent would likely be closer to:

let counts = new Map();
counts.set(key, (counts.has(key) ? counts.get(key) : 0) + 1);

[LinusU]

Admittedly, I'm not very well versed in ecma specifications. But reading the specification, I don't see anything about it calling has on subclasses:

https://tc39.es/proposal-upsert/#sec-map.prototype.getOrInsert

---

But yes, I meant functionally equivalent in the sense of "maintaining a counter", not necessarily that the code internally does exactly the same thing. E.g. another difference is that it calls set(0) and after that set(1) in the previous version, which doesn't happen in my new version.

[senocular]

@LinusU Yes, maintaining a counter may not be a good use case for getOrInsert. While not functionally equivalent to using getOrInsert, your version does a better job because it checks for a key not existing or its value being nullish, whereas with getOrInsert (or ljharb's more functionally equivalent implementation) it only checks for the key not existing. For example if the map was initialized with

let counts = new Map([[key, undefined]]);

the getOrInsert version would result in NaN while yours would be 1.

Effectively, if you're going to set a new value regardless, getOrInsert is only useful if it makes sense to include the has check.

[ljharb]

ah yes, you're right that it doesn't observably call has, but it also doesn't observably call get :-)