2007/8/3, Andreas Raab <andreas.raab at gmx.de>:
> Damien Cassou wrote:
> > What don't you like? If I have no feedback, I can't improve and learn.
>
> One of the things that I personally don't like is that you seem to be
> repeating the same conceptual mistakes of the original library. For
> example, what is the *conceptual* difference between an
> NSReadableCollectionStream and an NSWriteableCollectionStream and an
> NSReadWriteCollectionStream? These seem arbitrary (and not very helpful)
> distinctions that would be better modeled by having a single
> NSCollectionStream which -if that is really necessary- has an attribute
> controlling whether it's going to be used read-only or not.


Thank you very much, I really appreciate that kind of feedback. And,
without much more thinkning, I agree with you: we don't really need
that distinction; it complicates things and this is not really useful.
I will try and let the list know. However, we will break backward
compatibility.

Do you suggest that we only need  ReadWriteCollectionStream (which we
have already)?

> If I were to rewrite streams I'd actually start at a different point.
> Not by making these micro-distinctions about readability and writability
> (which seem to make up most of the traits in the version that I looked
> at)


There are 3 main traits:

- one for reading elements sequentially (you just have #next, #peek
and derived methods like #do: #next:...)
- one for writing elements (you just have #nextPut: and derived methods)
- one for positioning in the stream (#position: #position...)

We chose this decomposition because it was the way ANSI defines
Streams and to keep compatibility with the current stream hierarchy.


> but rather define three basic types of streams:
> * Internal streams: Which are collections+cursor, providing the full
> collection interface to streams (which is hugely useful).


this is done but we could do better. For example, we have #do: and
#select:, but other enumerating messages are missing. And #select:
returns a new stream, not a collection. Is this what you are thinking
about?


> * External streams: Which are modeling I/O (so they are potentially
> infinite sources, can block, are often asynchronous etc)


we already modeled File streams. It's incomplete however.


> * Translating streams: Which are streams that perform operations on
> other streams (CRLF conversions, compression, decompression)


This is done. Filters can be created easily.


> If you were to structure a stream library along these lines I think
> you'll find that most of the uses for traits would go away because
> besides the core protocol (which would appear in class Stream) there is
> actually very little duplication of responsibilities in there.

I do not agree. We will see what I can do and will discuss about this
later if you want. But, yes it's possible to avoid duplication,
writing all the methods in the Stream class.

When you have a read-only stream (as with audio/video streams for
example) you really don't want the writing protocol I think. In this
case, you prefer using only the traits that make sense for your class.

-- 
Damien Cassou