commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: [io] docs and refactorings
Date Mon, 29 Dec 2003 00:49:30 GMT

In the end, the prime aspect is 'what will be used together'. That's what
makes a package. I view this as what will one piece of code use, not one
huge application.

I think it's more likely that we'll see 3 InputStream's chained, or using
Proxy or something, than for an OutputStream to be used.

That's my entire justification for keeping in/out separate :)

Should InputStream and Reader be separate? I think it's not that common to
use Reader and InputStream together, but it's a lot more common than using
with OutputStream. As Reader may be written in terms of InputStream, I can
see that it makes sense to keep these guys together.


I guess another way to view it is in terms of search parameters,
hierarchical search not google. I feel I'm far more likely to walk up to
the javadoc and say:  "I need a Writer, make it a Counting", than  "I need
a Counting, make it a Writer".

Proxy is a bit of a special case I think, as I'd like to see a nice jar
full of handy proxy classes :) This is because I would walk up to said
javadoc and ask for a proxy, then choose the class I want to be proxied.

[end of babble]

Hen

On Sun, 28 Dec 2003, Stephen Colebourne wrote:

> The situation is no different to [collections], where we have PredicatedXxx,
> TransformedXxx, TypedXxx etc. In the end, the prime aspect is the type of
> collection, not the type of decoration.
>
> This can be argued both ways, but it would be nice for [io] to follow
> [collections] ;-)
>
> Stephen
>
> ----- Original Message -----
> From: "__matthewHawthorne" <matth@phreaker.net>
> > There are 3 examples in the current [io] codebase:
> >
> > Counting [InputStream, OutputStream]
> > Demux [InputStream, OutputStream]
> > Proxy [InputStream, OutputStream]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message