@BridgeAR build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/1919/pipeline

I find this very confusing. ArrayBuffers don't have an underlying Uint8Array, it's the opposite.

@targos yes, I described it wrong. The point is, that inspecting two different ArrayBuffer directly can result in the same output while belonging to a very different TypedArray. This makes sure it's clear to the viewer.

I am also happy with a different representation but this was the best I could come up with.

An alternative representations I thought about was:

ArrayBuffer { byteLength: n } [Uint8Array] [...]

CI https://ci.nodejs.org/job/node-test-pull-request/19480/

@nodejs/util PTAL

Since ArrayBuffers are the data holders for all typed arrays, I don't think it's a good idea to show the contents as Uint8Array. How about we do the same as with Node's Buffers and display it in hexadecimal form?
I'm also fine with the current state of things. It's easy enough to wrap the ArrayBuffer in any typed array to have the desired output.

@targos I am fine with using a hexadecimal representation but I am not sure how to name the "property" (description) in that case. I could keep it as Uint8Array but it might be somewhat confusing that way?

About the current state: I think it's nice to see as much as possible right away but more important: it helps identifying different ArrayBuffers from each other right away. This also has impact on e.g. comparing two ArrayBuffers with assert as the error message could be is misleading until it's possible to distinguish them.

@targos @addaleax what do you think of either of these representations (or any potential combination of some of these):

1. 'ArrayBuffer { <Uint8BufferView 68 65 6c 6c 6f>, byteLength: 4 }'
2. 'ArrayBuffer { <Uint8Array 68 65 6c 6c 6f>, byteLength: 4 }'
3. 'ArrayBuffer { <ArrayBufferView (Uint8) 68 65 6c 6c 6f>, byteLength: 4 }'
4. 'ArrayBuffer { [TypedArray]: <Uint8Array 68 65 6c 6c 6f>, byteLength: 4 }'
5. 'ArrayBuffer { <ArrayBufferView 68 65 6c 6c 6f>, byteLength: 4 }'
6. 'ArrayBuffer { [ArrayBufferView as base64]: 'aGVsbG8=', byteLength: 4 }'
7. 'ArrayBuffer { <Base64 ArrayBufferView aGVsbG8>, byteLength: 4 }'

I personally think it's important to tell the user that it is represented as Uint8. In what way and with what other description is not really as important for me. Without that information it's hard to understand what the representation actually stands for.

@BridgeAR I think 2, 3, 4, 5, 6 are misleading because they imply an associated ArrayBufferView in one way or another that does not actually exist. I think 6 and 7 are not useful, because base64 does not provide much visual information about the contents, only a way to reconstruct it.

I’d prefer for visual clutter/“specialness” to be minimal, so maybe a pseudo-property like [Uint8Contents]: <68 65 6c 6c 6f> would work?

I personally think it's important to tell the user that it is represented as Uint8.

I’m not sure I agree – we don’t do this for Buffers either, hex characters grouped in 2s are pretty much the standard representation for uint8 sequences, so it’s not really ambiguous.

@addaleax

hex characters grouped in 2s are pretty much the standard representation for uint8 sequences, so it’s not really ambiguous

Sounds fine to me.

I’d prefer for visual clutter/“specialness” to be minimal

Coming from your suggestion, here's a new set of possibilities. I personally prefer 1 and 2 while not having a strong preference for either. I think 3 and 5 lack a description of the "value" (looking at it alone), otherwise I would also go for a pseudo property.

1. 'ArrayBuffer { <Content 68 65 6c 6c 6f>, byteLength: 4 }'
2. 'ArrayBuffer { <Uint8Content 68 65 6c 6c 6f>, byteLength: 4 }'
3. 'ArrayBuffer { [Content]: <68 65 6c 6c 6f>, byteLength: 4 }'
4. 'ArrayBuffer { [Content]: <Uint8 68 65 6c 6c 6f>, byteLength: 4 }'
5. 'ArrayBuffer { [Uint8Content]: <68 65 6c 6c 6f>, byteLength: 4 }'

Alternatives: Data, Contents

/cc @nodejs/util

@BridgeAR I think my personal preferences would be 5, 3, 2, 1, but let’s see what others think :)

Re: content vs contents, maybe it’s best to leave that to a native speaker?

@addaleax the difference between content and contents is AFAIK subtle and depends on if we see the contained information as a whole (content) or if we consider it to be separate parts of information (contents). But by all means: I should not be the person to decide this :D (and I am also fine to use Data).

@Trott @vsemozhetbyt would you two be so kind and have a look at this? :)

Thinking about it: we could maybe use a team (e.g. nodejs/native-english-speaker) for pinging people with a very good English language knowledge (ideally both, British and American English. I for example struggle that)?

@targos do you have a preference for the last suggestions?

@Trott @vsemozhetbyt would you two be so kind and have a look at this? :)

In this particular case, I think contents is slightly more appropriate than content, but either will do. https://dictionary.cambridge.org/us/grammar/british-grammar/content-or-contents is a pretty good explanation of the subtlety. content is something that is uncountable, whereas contents is something that is enumerable. So in this case, contents is better, but no one will think it sounds strange if you use content instead.

PTAL. I reworked the output as discussed.

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

@nodejs/util @addaleax @targos PTAL

This needs some reviews.

Rebased due to conflicts. PTAL, this needs a review.

CI https://ci.nodejs.org/job/node-test-pull-request/19846/

CI: https://ci.nodejs.org/job/node-test-pull-request/19903/

Resume CI: https://ci.nodejs.org/job/node-test-pull-request/19976/

Landed in aa07dd6

@BridgeAR fyi, this would need a manual backport to v11.x-staging