Similarly to the way the drain() method gives *implementations *the flexibility to return a different ByteBuffer, I wanted to also give *callers *the flexibility to drain a different ByteBuffer. I don't have a concrete use case for it, but I imagined there might be cases where callers overflowed content into another buffer which would need to be drained separately.
I don't want to modify the signatures of the ByteBufferDestination interface. It would break binary compatibility for no good reason. On Mon, Feb 27, 2017 at 10:33 AM, Matt Sicker <boa...@gmail.com> wrote: > Since all our implementations of ByteBufferDestination return a shared > ByteBuffer in getByteBuffer(), I don't see why it needs to be provided to > the drain() method. drain() returns the buffer (or a new one in the case of > MemoryMappedFileManager), and I don't see why an assumption could be made > that the buffer you're draining is the exact one the destination already > knows about. Is there a particular use case why this might not work? > > -- > Matt Sicker <boa...@gmail.com> >
