On Mon, Jul 14, 2008 at 10:02:00AM +0200, Stefano Bagnara wrote:
> Oleg Kalnichevski ha scritto:
> >Stefano Bagnara wrote:
> >>In java core classes a stream wrapping another stream extends 
> >>FilterInputStream. BufferingInputStreamAdaptor cannot extends 
> >>BufferingInputStream and FilterInputStream because we don't have 
> >>polymorphism, but I think we should better name the class 
> >>BufferingInputStreamFilter because Adaptor let me think of something 
> >>converting an object in another type of objects, instead this simply 
> >>wrap a stream adding buffering.
> >>
> >
> >Stefano,
> >
> >BufferingInputStreamAdaptor does not really add buffering to a stream. 
> >It rather adds ability to read lines to input steams that do not support 
> >BufferingInputStream interface natively. Thus, I felt adapter was a 
> >better name for this class. I personally find filter misleading as there 
> >is no filtering going on in this class.
> 
> Make sense! Thank you for the explanation.
> 
> Filter would not be bad anyway because of this javadoc from 
> FilterInputStream: "A FilterInputStream contains some other input 
> stream, which it uses as its basic source of data, *possibly* 
> transforming the data along the way *or* providing *additional* 
> functionality", but I now agree that BufferedInputStreamFilter would be 
> much more misleading than the current name.
> 
> >Anyways I will not stand in your way if you think differently
> >
> >Oleg
> 
> If we apply MIME4J-50 we have
> 
> FilterInputStream
> '- BufferingInputStream
>    |- BufferingInputStreamAdaptor
>    |- InputBuffer
>    '- MimeBoundaryInputStream
> 
> In fact only InputBuffer and MimeBoundartInputStream provide buffering 
> while "BufferingInputStream" is an abstract for "line reading to buffers".
> 
> Maybe we should rename the tree somehow similar to this:
> 
> FilterInputStream
> '- LineReaderInputStream
>    |- BufferedInputStream
>    '- MimeBoundaryInputStream
> 
> And have LineReaderInputStream already including the current 
> BufferingInputStreamAdaptor code. We just don't need the abstract if we 
> have a simple class for the most basic implementation.
> 
> WDYT?
> 
> Stefano
> 

Hi Stefano

I am fine with renaming the classes but I would like to keep the
adapter class separate. It basically contains some ugly plumbing code
which I would not like to pollute the LineReaderInputStream code with.
I really would like to keep that inefficient, one byte at a time line
reading code hidden away as much as possible.

Oleg



> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to