util: add Set and Map size to the inspect output

[BridgeAR]

This adds the set or map size while serializing those with inspect().
That aligns the output with the one from Chromium. To do so, I refactored some code that special handled iterators that had the prototype set to null. That is not required anymore. It was necessary to bind some properties to later on used functions to keep the performance profile in tact and the implementation similar to the way it used to work.
Due to the refactoring a few more edge cases will also from now on be handled properly (inspecting a set or map with a broken iterator symbol or the size property manipulated will still work).

This should be semver-minor, since we explicitly note that people should not rely on the inspect output programmatically.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[addaleax]

Would it be a bit more intuitive (and more consistent) to handle this like we do for e.g. ArrayBuffers, i.e. print size as a property (which is how you’d access it in JS)?

> a = new ArrayBuffer(4)
ArrayBuffer { [Uint8Contents]: <00 00 00 00>, byteLength: 4 }
> a = new Map([[1,2],[3,4]])
Map { 1 => 2, 3 => 4, size: 2 }

[devsnek]

I don't think it's immediately clear what the number on the map means. Can we just show 'size' as a normal property? if someone overrides it they probably would want our inspection to show the overridden one anyway.

[BridgeAR]

I am fine to print that instead. This implementation is just not possible to manipulate. The other one could show something else (I actually added a test for that).

[BridgeAR]

Just as a note: I personally think the shorter notation is nicer to read (even though it definitely requires a short moment to understand the number when seeing this notation for the first time).

I updated the implementation nevertheless. PTAL.

[addaleax]

I find the brackets around [size] weird and would recommend to omit them, but either way this LGTM

[joyeecheung]

This is how things look like in the Chrome DevTools BTW.

Do we really need to display the size when the number of entries are small enough so that they are all displayed?

Outdated due to a changed implementation.

[BridgeAR]

I went ahead and created a twitter pool for this: https://twitter.com/BridgeAR/status/1195687117080408067
I tried to keep the question as neutral as possible.

Seems like 72% of all 115 participants would like to have the size as part of the default output. 28% are happy with the output as it is.

62.5% percent (of the 72%) are in favor of Set(n) { ... } or Map(n) { ... } while 37.5% would favor output similar to a property (the latter number is the sum of the output visualized as own property and as computed/prototype property).

I therefore went back to my initial implementation. @addaleax I removed your LG due to that change. PTAL

@joyeecheung we could in theory only add the number in a couple of cases (depending on the size). Set and Map entries can in general look very different though and in some cases it might be straight forward to see how many entries they are while it's more difficult in other cases. Thus I think it's best to be consistent. Especially as it might also be confusing to some users to see different output depending on the size.

@nodejs/util PTAL

[BridgeAR]

Rebased due to conflicts @nodejs/util this could use some reviews.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/27310/ ✔️

[targos]

I think this can be semver-patch. There are no additions to the public API.
Edit: could stay semver-minor if you think the change is substantial enough.

[BridgeAR]

I am fine with this being a patch as well. We treat most of our util changes as patches. I'll follow your recommendation while I am fine both ways.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/27448/ ✅ (yellow build with a known Windows flake)

[Trott]

Out of caution, here's a CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2127/ ✔️

[BridgeAR]

Landed in eeae598, ab59989 🎉

[targos]

This doesn't land cleanly on v12.x-staging and probably depends on previous PRs that were not backported yet.