Does ByteBufferDestination.drain() even need an argument?

[Matt Sicker <bo...@gmail.com>]

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 <bo...@gmail.com>

Re: Does ByteBufferDestination.drain() even need an argument?

[Remko Popma <re...@gmail.com>]

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 <bo...@gmail.com> 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 <re...@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 <bo...@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 <bo...@gmail.com>
>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>

Re: Does ByteBufferDestination.drain() even need an argument?

[Matt Sicker <bo...@gmail.com>]

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 <re...@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 <bo...@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 <bo...@gmail.com>
>>
>
>


-- 
Matt Sicker <bo...@gmail.com>

Re: Does ByteBufferDestination.drain() even need an argument?

[Remko Popma <re...@gmail.com>]

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 <bo...@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 <bo...@gmail.com>
>