Thank you Alan! I’ll try to address each of your points, apologies if I miss
anything:
Maybe the two efforts should be separated.
I’m good with that, and will operate that way unless someone argues otherwise.
The factory methods can return a different implementation, in particular
BAOS.unsynchronized (or whatever name it gets) does not need to collect the
bytes in a contiguous array. So having a BAOS.unsynchronized may help with some
of the scenarios that you are looking at.
I think this is a clever way to go and I’m in favor… just not sold on the
name. I won’t abandon the effort if you feel otherwise. 😊 Let me know if
we’re ready to proceed with this or another name.
I think the PR proposing MemoryOutputStream is a bit premature
This was intended solely to share code for discussion, and it’s been
effective in that sense. I agree that the PR is nowhere near merging.
Maybe you have explored a segment like API or a cursor or consumer API to
handle the bytes?
The current version of the PR is along these lines, providing one public
class whose contents are available via views (SeekableByteChannel, BAOS,
ByteArrayInputStream) as well as the usual add/write/updates, long size(), and
lambda-based applyToSegment(Function) and applyToIndex(Function). The public
wrapping needs to evolve but I think these provide the core of the API.
John
