David M. Lloyd wrote: > 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.
Great point. We should see composite byte buffer from the buffer management perspective. Actually I was somewhat confused about my own idea because composite buffer can be implemented in both layer. Drawing a strict line seems to be a good idea. >>>> 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. Agreed. We will definitely have a chance although we don't need to hurry up too much. Thanks, -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
signature.asc
Description: OpenPGP digital signature
