Hi Trustin I've been looking into the CompositeIoBuffer issue (DIRMINA-489) over the last few weeks, so I'm following the current discussion with interest. Overall, I think your suggested interface is good, but I do have a few comments and suggestions.
- I like the idea of providing an abstraction for a sequence of bytes that has a relatively small set of operations. This will make it easier to provide different implementations. (I was actually planning to write a code generator to reduce the work involved writing all the different combinations of absolute/relative getters/setters for each different type!) - Removing the relative operations also makes it easier to share the objects, since there is less state to be messed up. - However, in a composite implementation, where the actual byte storage is spread over a sequence of underlying objects, there may be a cost associated with random access. Since a lot of real access is in fact going to be sequential, it might make sense to provide something like an "iterator" to efficiently support this usage pattern. In my (unfinished) CompositeIoBuffer implementation, I used a private iterator class to implement the buffer's position and mark. This made them a lot easier to use, since it encapsulated away the details of how to efficiently traverse the component buffers. - Does the ByteArray interface provide operations for expansion, or would this be subclass-specific behaviour? I'm guessing expansion is a subclass-specific, since the javadoc says that a ByteArray is fixed size. - Were you thinking that asByteBuffer() would return the ByteArray's backing ByteBuffer, or on implementing a version of ByteBuffer that delegates to the underlying ByteArray? If it's the former, then it's probably worth thinking about the desired semantics for a CompositeByteArray. Do we need to guarantee that modification of the returned array will always modify the underlying ByteArray? I think it would be possible to *almost* implement this for a CompositeByteArray, i.e. by first copying all component buffers into a single buffer, then returning its ByteBuffer. But if we then added another buffer to the CompositeByteArray (expanding it) and called asByteBuffer() again, we'd need to create another ByteBuffer. So we'd now have two different ByteBuffers returned by this method, and the first ByteBuffer would become "disconnected" from the underlying ByteArray. I hope that made sense! Cheers Rich On Tue, Apr 29, 2008 at 2:20 PM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote: > Hi folks, > > I tried a quick prototyping of the ByteArray interface I've mentioned in > our previous discussion thread. I wanted to check in the code right now > for easier review, but ASF-wide SVN write access has been disabled due > to some hardware issue. Let me paste it here: > > http://pastebin.com/m37fb44ba > > The idea is to implement a ByteBuffer-backed ByteArray class and > implement some variable length buffer-of-arrays using it. WDYT? > > -- > Trustin Lee - Principal Software Engineer, JBoss, Red Hat > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > > -- Rich Dougherty http://www.richdougherty.com/
