doc: document default length as buffer.length

[wbt]

The Buffer documentation documents the 'buf.length' property as:
'Returns the number of bytes in buf.'
It uses the .length property in its own internal references on that page.
Buffer.byteLength is a static function which takes a string parameter.
The documentation was confusing; this PR should help clarify it.

[wbt]

One character over on one line of a commit comment. Kind of frustrating to have to redo for that! Maybe someone else can pick it up from here.

[tniessen]

I personally don't think this makes it much clearer. buffer.byteLength is correct for Buffer and TypedArray, whereas buffer.length is only correct for Buffer (and Uint8Array).

buffer.byteLength is always correct, buffer.length is not.

[wbt]

According to the documentation, Buffer.byteLength is a function that does not return the number of bytes in the buffer. Buffer.length does provide that data.

[tniessen]

@wbt Buffer extends Uint8Array. buffer.byteLength is the instance property that is inherited from Uint8Array. Buffer.byteLength() (capital B) is the static method.

[wbt]

@tniessen Does the latest commit seem to provide more helpful clarification?

[aduh95]

FWIW I agree with Tobias, we should keep referencing .byteLength – it's also what the code is doing.

[aduh95]

I think it's more correct to say it's the inherited buf.length – which happens to be the same as buf.byteLength. I would remove this change from this PR.

[github-actions]

This issue/PR was marked as stalled, it will be automatically closed in 30 days. If it should remain open, please leave a comment explaining why it should remain open.

[wbt]

I think there's still a useful contribution, but blockers like being one character over on a commit comment underscore somewhat artificially high barriers to contribution here.

[RedYetiDev]

I think there's still a useful contribution, but blockers like being one character over on a commit comment underscore somewhat artificially high barriers to contribution here.

Chances are your contribution is useful :-), but if you'd like to provide information about the "artistically high barriers", please open a new issue, and im sure members of Node.js will be happy to discuss!

[wbt]

The PR was originally rejected because one of the six commit comments was a single character too long, and the process of trying to go through and change history is a nontrivial amount of work relative to the size of the proposed change.

If someone's interested in learning more about the large total value of contributions that is discarded when small valuable contributions are no longer worth making because the cost of making the contribution exceeds the value of the individual contribution, I'd recommend Clay Shirky's books (example here) as an entry point. While I don't think the barrier to contribution should be at zero, I don't think it should be higher than is really necessary and this rejection really felt like a strong example of the barriers being higher than necessary.

[RedYetiDev]

Here are the instructions, at least how I understand them

1. Rebase

git rebase -i HEAD~6

2. Squash
   Replace all picks with squashes (except the first one)
3. Commit
   Comment out all the commit messages, and insert a new one

[jakecastelli]

Hi @wbt please don't feel discouraged, if you don't mind resolving the conflict, I could help you make the commit message body pass the pipeline check (as a vim user this is really just press gq to wrap the line which takes me less than a second to do), and agreed that maybe some toolings or scrips should be there for resolving this kind of frustration from contributing.