Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inclusion on Uint8Array #10

Closed
syg opened this issue Jul 14, 2021 · 9 comments
Closed

Inclusion on Uint8Array #10

syg opened this issue Jul 14, 2021 · 9 comments

Comments

@syg
Copy link

syg commented Jul 14, 2021

How about also including it on Uint8Array? To me, the primary benefit would be to get encodings of subarrays without copying, since TAs are already views.

@lifaon74
Copy link

I agree on this, usually we work with Uint8Array for binary data

@zloirock
Copy link

zloirock commented Jul 26, 2021

uint8array.buffer.toBase64() anyway should work, so why?

...

However, yes, Uint8Array.fromBase64(string) is much shorter than new Uint8Array(ArrayBuffer.fromBase64(string)).

@LinusU
Copy link

LinusU commented Jul 26, 2021

uint8array.buffer.toBase64() anyway should work, so why?

Not necessarily, that could end up encoding more data than you want since the underlying buffer can be larger than the view.

@zloirock
Copy link

Right, I forgot this use case.

@bakkot
Copy link
Collaborator

bakkot commented Mar 24, 2023

Agreed, especially in light of #13 - you can "walk" Uint8Array views over a large ArrayBuffer to encode it piecewise, for e.g. sending over a network.

I'm not sure if it should go on Uint8Array as well as or instead of on ArrayBuffer.

@annevk
Copy link
Member

annevk commented Apr 21, 2023

Starting out with just Uint8Array makes sense to me.

@bathos
Copy link

bathos commented May 22, 2023

It feels pretty off to me for this to live on Uint8Array specifically given (a) the existence of Uint8ClampedArray as a “sibling” class that’s no less appropriate and (b) the fact that these string codings don’t imply anything about the interpretation of the binary data. A base64 string could as readily encode variable-size-element structured data that only makes sense to read using DataView, say (a real world example of such data people do sometimes transfer using base64: fonts).

@bakkot
Copy link
Collaborator

bakkot commented May 22, 2023

the existence of Uint8ClampedArray as a “sibling” class that’s no less appropriate

Uint8ClampedArray is definitely less appropriate - it's only for very niche cases where you want to have special behavior on assignment. Uint8Array is the canonical "sequence of bytes" typed array.

the fact that these string codings don’t imply anything about the interpretation of the binary data

Right, which is what makes Uint8Array an appropriate type - it's represents a sequence of bytes. The only difference between Uint8Array and ArrayBuffer is that Uint8Array is a view, which makes it strictly more useful - it lets you read decoded bytes directly, in those cases where that's appropriate, and it lets you encode only a part of a block of memory without doing a copy.

@bakkot
Copy link
Collaborator

bakkot commented Feb 8, 2024

Closing as settled; this will be on Uint8Array.

@bakkot bakkot closed this as completed Feb 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants