-
-
Notifications
You must be signed in to change notification settings - Fork 34.5k
Description
What is the problem this feature will solve?
From the docs:
Node.js APIs accept plain
Uint8Arrays whereverBuffers are supported as well.
One notable place where plain Uint8Arrays are not always accepted is the methods on the Buffer subclass. Take the method buf.readIntLE(offset, byteLength):
Buffer.prototype.readIntLE.call(Uint8Array.of(1, 0, 0, 0, 0), 0, 3);
// 1
Buffer.prototype.readIntLE.call(Uint8Array.of(1, 0, 0, 0, 0), 0, 4)
// Uncaught TypeError: this.readInt32LE is not a function
// at Uint8Array.readIntLE (node:internal/buffer:349:17)Depending on the byteLength given, the method will respond correctly or throw a TypeError if it happens to be written using a code path that uses an internal method found only on the Buffer prototype.
As a library author, I would also like to easily accept Uint8Arrays wherever Buffers are accepted and not spend time converting the input to a Buffer instance to get useful byte utilities to work on both possible inputs.
What is the feature you are proposing to solve the problem?
I propose to make the few code paths that rely on internal methods invoke those functions in a way that doesn't require them to be defined on the currently bound this value's prototype.
For example:
return this.readInt32LE(offset);becomes
return FunctionPrototypeCall(readInt32LE, this, offset);And add coverage for existing and future methods to maintain this contract.
What alternatives have you considered?
A couple but less desirable alternatives:
- Convert input by invoking
Buffer.from(ArrayBuffer, byteOffset, byteLength) - Reimplement the methods in library to work with either input
Metadata
Metadata
Assignees
Labels
Type
Projects
Status