Replace ByteArray with native ES6 TypedArray
I believe it's possible to replace the ByteArray
module with a native ES6 TypedArray: in particular, Uint8Array
.
Currently, C functions with GBytes
and GByteArray
input parameters take a ByteArray
in Javascript, and output parameters of GByteArray
and uint8_t*
type are converted to a ByteArray
in Javascript. (Output parameters of GBytes
type end up as a GLib.Bytes
object in Javascript. I don't know why this inconsistency exists.)
My proposal would be to replace ByteArray
with Uint8Array
everywhere. The imports.byteArray
module would still exist, and provide the same ByteArray.fromString()
and ByteArray.fromGBytes()
static methods as before, which would now return Uint8Array
s. It would also provide ByteArray.toString()
and ByteArray.toGBytes()
static methods to replace the ByteArray
instance methods of the same names.
A legacy shim would provide ByteArray
as an alias for Uint8Array
and add toString()
and toGBytes()
methods to Uint8Array.protoytpe
for compatibility with existing code. It would also provide a ByteArray.fromArray()
static method for compatibility, though that is entirely equivalent to Uint8Array.from()
. These legacy methods would be considered deprecated from the start.
This should allow removing quite a lot of C++ code. However, unlike the existing custom ByteArray
, TypedArrays do not have a mutable length. (The array itself is mutable, but the underlying buffer cannot be grown or shrunk.) So, Javascript code that extended or appended ByteArray
s would need to be changed. The changes required should be trivial in most cases.
As an alternative that would preserve more compatibility, I might be able to write a shim that keeps existing ByteArray
code mostly working by implementing a separate ByteArray
class in JS, but it's not going to be possible to stay 100% compatible because in the end you have to return either a ByteArray
or a Uint8Array
instance from C functions with byte array return values.