Re: Does ByteBufferDestination.drain() even need an argument?
Yes, ByteBuffer is only useful for binary data. Using it for text would be painful. On Mon, Feb 27, 2017 at 2:55 Matt Sicker wrote: > 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 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 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 > > > > > > -- > Matt Sicker >
Re: Does ByteBufferDestination.drain() even need an argument?
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 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 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 >> > > -- Matt Sicker
Re: Does ByteBufferDestination.drain() even need an argument?
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 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 >
Does ByteBufferDestination.drain() even need an argument?
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