On Wed, 21 May 2008 10:08:27 +0900, Emmanuel Lecharny
<[EMAIL PROTECTED]> wrote:
We may need to deal with bits. ASN.1 PER decoder needs it.
Yes. Probably in the decoder? I don't think we should have bit
getters/putters in our interface. Then we should add all the bells and
whistles together. :)
All methods have been named after the methods in Queue, so it might
sound a little bit long, but it shouldn't be a problem in the long term
with the codec generator.
Just a question : do we need all those offerXXX() methods ? The type
will be enough to select the correct method. And I also suggest that the
default implementation should be for bytes, and that we have inherited
classes for int, float, etc... which would make the implementation much
easier (less methods).
We need them like ByteBuffer provides them. It's also important from
performance perspective because reading 8 bytes in a row with one call
often outperforms reading 8 bytes with 8 calls. We are going to provide
access methods for all primitive types (except for boolean) eventually so
I don't think it will lead to less methods in total.
Another things would also be to get a byte[] getBytes( in length )
method returning as much bytes as possible, up to a length. If the
number of available bytes is below the length, the returned byte array
will only contains the available bytes, and it will be up to the decoder
to deal with it. The idea is to avoid calling the element() method for
every single byte we want.
It sounds similar to ByteBufferQueue.pollSlice(int length), but
pollSlice() returns null when there's not enough data. It should be
basically identical to pollSlice(length()), and therefore it's just a
shortcut method. So.. I think we already have enough methods for this
case. WDYT?
Thanks,
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
