On 04/28/2008 12:34 PM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote:
David M. Lloyd wrote:
On 04/28/2008 11:39 AM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote:
I'd prefer to introduce an interface type because ByteBuffer is
impossible to extend.
That's fair, but I don't see why you'd need to extend ByteBuffer anyway?
Because we can't create a Composite ByteBuffer by extending ByteBuffer.
ByteBuffer also has unnecessary stuff like position, mark, limit,
flip(), compact() and order() which changes the state and behavior of
the buffer. There's no way to make the position and limit read-only
while making the buffer content writable.
You don't really need an actual composite ByteBuffer though. You'd just
have to make sure that all the send receive methods can handle more than
one ByteBuffer at once. You could even make a separate class that can do
the heavy lifting for you (this is why I keep mentioning DataInput/Output,
though their default implementations aren't terribly efficient). In a way
this isn't *too* different from the two-class approach you mentioned,
having a separate "array" vs "buffer management" class. You'd just use
ByteBuffer directly for the "array" class.
My long term idea is to write something similar to ANTLR (parser
generator) which works in a binary level; we can call it decoder
generator.
This would be better. ;-)
Yeah. The only problem is all nice parser generator implementations
depend on InputStream and consequently blocking I/O. We need to write a
new generator which works with non-blocking I/O.
Yeah, this is my complaint too. I've started work on more than one
occasion on a DFA bytecode generator that works in a non-blocking fashion.
But this is not a small task and unfortunately it is low on my list of
priorities. :-)
Maybe a collaboration is possible with the ANTLR project to achieve this goal.
- DML
