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

Support all TypedArray primitives #8

Closed
mkapal opened this issue May 5, 2024 · 4 comments · Fixed by #11
Closed

Support all TypedArray primitives #8

mkapal opened this issue May 5, 2024 · 4 comments · Fixed by #11
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@mkapal
Copy link

mkapal commented May 5, 2024

I'm happy to have found this library, it looks very promising!

One thing I'm missing is support for converting all primitives from the TypedArray group - that is all signed/unsigned integers, 16-bit integers and BigInts.

Do you plan to add those in the near future? Or I could try to do it myself and create a PR.

@mkapal mkapal changed the title Support all TypedArray objects Support all TypedArray primitives May 5, 2024
@iwoplaza iwoplaza self-assigned this Jun 28, 2024
@iwoplaza iwoplaza added the enhancement New feature or request label Jun 28, 2024
@iwoplaza
Copy link
Owner

Thank you for the suggestion! It does seem to be a rather general feature, enough to be included in the library. I will start work on it asap, apologies for the late response 💜

@iwoplaza iwoplaza added this to the 4.1.0 milestone Jun 28, 2024
@iwoplaza
Copy link
Owner

I am currently wondering about one thing. Lets say we have the following code:

import { object, string, u8array } from 'typed-binary';

const Packet = object({
  label: string,
  data: u8Array(64),
});

const buffer = /* getting the data from somewhere */;
const reader = new BufferReader(buffer);

// type of packet inferred as { label: string, data: Uint8Array }
const packet = Packet.read(reader);

packet.data[0] = 'B'; // does this mutate `buffer`, or not?

Basically the question is, is packet.data a view into buffer (less copying, more efficient to read), or is it a copy (safer, more consistent behavior). I am leaning towards copying, just because if buffer changes, packet.label is not going to change, but packet.data IS going to change, and that's not consistent.

@mkapal
Copy link
Author

mkapal commented Jul 29, 2024

I also think it should make a safe copy of the buffer so mutating it would not affect the original buffer.

@iwoplaza
Copy link
Owner

iwoplaza commented Sep 9, 2024

@mkapal The implementation and docs should be ready for a review, would love if you could take a look at it before merging 💚

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants