Thanks andreas
This is indeed interesting.

In fact we follow the ansi decomposition and forced ourselves to be  
backward compatible to avoid that people
complain as usual and bash us about wanting to break things and so  
on. But may be this was a mistake.

Now in the process we got a really good test suite for streams and we  
could rethink the traits recomposition.
We should give some thoughts about your suggestions but thanks for  
having say that

Stef

On 3 août 07, at 00:37, Andreas Raab wrote:

> 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.
>
> 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) 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).
> * External streams: Which are modeling I/O (so they are potentially  
> infinite sources, can block, are often asynchronous etc)
> * Translating streams: Which are streams that perform operations on  
> other streams (CRLF conversions, compression, decompression)
>
> 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.
>
> Cheers,
>   - Andreas
>
>