harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [classlib][archive] Re: Delayed entry parsing
Date Fri, 28 Mar 2008 16:25:26 GMT
Tim,

Actually I was thinking of benefits of extending ByteBuffer and
returning ByteBuffer instance from the static method. Imagine a time
when the same ByteBuffer would be used through the whole
implementation starting from a memory mapped file till UTF-8 decoder
input, and only relative positions would be passed around.

The reason why I did not use the ByteBuffer for return type was I was
unable to find enough arguments for that complication right now. May
be Alexey's MANIFEST would be the case when it would be convenient
just to shift the last buffer position a over a nul character.

Folks, I need your opinion to either rename the class or change return
type to a slightly heavier one.
Thanks!


On Fri, Mar 28, 2008 at 1:57 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Alexei Fedotov wrote:
>  > I have completed changes [1] based on your ideas of using
>  > ByteArrayInputStream child for exposing its underlying buffer as well
>  > as fixed few of my earlier TODO comments. I found the contract of the
>  > underlying buffer capturing close to ByteBuffer.wrap() method and
>  > named the class correspondingly.
>
>  Nah, ByteBuffer.wrap(byte[]) would return a ByteBuffer.  This is
>  reaching in and getting the implementation (i.e. almost the opposite).
>
>  We need to rename it.  How about InputStreamExposer#expose(InputStream).
>
>  Regards,
>  Tim
>
>



-- 
With best regards,
Alexei

Mime
View raw message