Hi Andreas,

2007/11/9, Andreas Raab <andreas.raab at gmx.de>:
> In a way, more so than before. The structure in the PDF looks reasonably
> simple but it leaves one wondering what the difference to just using a
> class hierarchy like the following would be:
>
> NSStream
>    NSPositionableStream
>      NSCollectionStream
>      NSFileStream


Sure. We also don't need NSStream and NSPositionableStream; they can
be merged. But in these cases, there is no way of having a class with
just read and positioning or just write.


> Looking at the code, the inability to distinguish between what method
> comes from which trait (something that is trivially to see by looking at
> the hierarchy) or which methods are overridden (again trivial with the
> hierarchy) make it the use of traits feel like an obfuscation of an
> otherwise quite reasonable design.


Use a recent browser and you will have a handful of information:

http://damien.cassou.free.fr/browsing-withTraits.png

In the screenshot, you can see that the currently selected method
comes from NSTPuttableStream. You can also see that #next is a local
method whereas #match: is implemented in a trait (it is in italic).
You also have a Trait button to show you the trait hierarchy used by
the current class.


> If I had the time I'd actually build a version of Nile using just the
> above structure to prove that point - I think it would be undeniable
> that the structure you are envisioning is quite reasonable but best
> implemented without using traits.

If you only look at CollectionStream and FileStream then yes, you can
do simpler. But the stream library is not limited to these two classes
and that's what make this library interesting.

-- 
Damien Cassou