Decide how to be compatible with BinaryStream

[dktapps]

It's desirable to implement a shim for BinaryStream using the extension so that we don't have to rewrite thousands of lines of code immediately to get the benefits of ext-encoding.

The current design of the API is pretty shitty. I want to split it into ByteBufferReader and ByteBufferWriter.

The problem is that, because of BinaryStream's design, any write calls need to influence the data read by read calls (because read/write share a buffer). This means that if we want to simulate BinaryStream using ByteBuffer, we need some way for a buffer being read to live-update when it's modified by a write() call, or accept quiet behavioural breaks (though realistically probably no one wanted this BinaryStream behaviour anyway).

My current thought on how to do this is something like the following:

• ByteBuffer wraps around string and handles only allocation logic, and has read(int $offset, int $length) and write(int $offset, int $length). No offset management to be done by ByteBuffer. ByteBuffer essentially becomes a boxed string.
• ByteBufferReader::__construct() would work with string|ByteBuffer. string because raw data will usually be strings, but ByteBuffer would allow sharing the same raw bytes between a reader and a writer.
• ByteBufferWriter::__construct() would accept ?ByteBuffer $buffer = null. Writer only requires a buffer to be given to avoid new memory allocations, but if none is given, it can happily create its own.

Alternative - Implement BinaryStream as a deprecated alternative directly in the extension

The question on my mind is whether we could just ditch ByteBuffer altogether in this scheme, even though it would make it impossible to make a sim for BinaryStream using ByteBuffer. In theory we can probably re-implement BinaryStream directly in the extension anyway since Serializers.h doesn't depend on any ByteBuffer stuff.

Not sure how best to proceed.

[dktapps]

On balance, it doesn't look that difficult to just re-implement BinaryStream. The important functionality is already implemented anyway.