Oh, alright, that makes sense. No need to change it, I was mainly curious since I'm working on some NIO stuff (from the other thread) and came to a point where I need to add a similar interface, though now I'm also seeing why a StringBuilder is used (I was trying to skip an intermediate step of formatting a log message by directly encoding the LogEvent into a ByteBuffer since this playground code doesn't have a need for complicated layouts, but ensuring the write buffer has enough space between each and every byte would be extremely tedious).
On 26 February 2017 at 19:48, Remko Popma <remko.po...@gmail.com> wrote: > 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> >> > > -- Matt Sicker <boa...@gmail.com>
