Emmanuel Lecharny wrote: > "이희승 (Trustin Lee) <[EMAIL PROTECTED]>" wrote: >> David M. Lloyd wrote: >> >>> On 04/28/2008 01:09 PM, Emmanuel Lecharny wrote: >>> >>>> May be but this is just a Buffer, not a data structure ! BB are really >>>> meant to be used as a fixed and temporary storage, not as something a >>>> user application can use at will. >>>> >>> Yes, I think the important change is to break the 1:1 association >>> between a buffer and a message. >>> >>> That's what this part of the thread is really all about I think. >>> >> >> Very true. I actually don't care even if we use NIO ByteBuffer as a >> underlying storage and build something on top of it. The problem is to >> find out how we can protect users from modifying position, limit, mark >> and order - these four properties must be handled in our abstraction >> layer, which breaks the 1:1 association. >> > Why do you want to protect those internal values ? The contract is > pretty clear, and if a user fucks with those values, eh, too bad for him !
If those internal values shouldn't be modified, then there should be zero possibility. Otherwise, it's not internal and the contract is too loose. API should minimize user's mistake wherever possible. > If we do care, maybe another option would be to transform those BB to > byte[] and let the user play with the limits by himself... Direct buffer is a show-stopper for that unfortunately. > But I do think that as soon as you have been burnt once with the limit, > position and mark, as a smart user, you RTFM and try to respect the API > contract :) That's what's called 'bad impression' IMHO. API should respect the user before the user respects the API. -- 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
