[ANN] Nile 0.9.5

Hi,

Nile is a complete reimplementation of the squeak stream hierarchy.
It's based on traits.

You can find it on Universe, SqueakMap, and SqueakSource
(http://www.squeaksource.com/Nile/)

A new class diagram is available at:
http://damien.cassou.free.fr/documents/internship_2007/nile/complete_hierarchy.pdf

Changes includes:
    * Only one class for collection-based streams (0 trait)
    * Only one class for file-based streams (0 trait)
    * Three new traits to put common behavior (6 traits in the core now)

We did these simplifications following Andreas Raab suggestions. It
proved to be a very good idea as a lot of entities (either class or
trait) has been removed. We are not ANSI compatible anymore but we
don't think it's a real problem in our case.

There is also a backward compatibility package (not loaded by default)
which contains  collection-based stream classes to mimic ANSI
behavior: NSReadableCollectionStream, NSWriteableCollectionStream and
NSReadWriteableCollectionStream. They are using the new core. Please
see package NileBackwardCompatibility on SqueakSource.

If you want to experiment ideas with Streams, you can do that on Nile
(for example, using a StreamAtEnd exception to avoid testing for
#atEnd).

Please comment on this.

--
Damien Cassou

thanks damien.
This is indeed simpler that way :)
So the feedback was good.
Stef

On 8 nov. 07, at 08:57, Damien Cassou wrote:

2007/11/8, stephane ducasse <[hidden email]>:
> This is indeed simpler that way :)
> So the feedback was good.

I think so. Andreas, what is your opinion about the new design? Do you
still think there are two much traits for a too small benefit?

--
Damien Cassou

Damien Cassou wrote:
> 2007/11/8, stephane ducasse <[hidden email]>:
>> This is indeed simpler that way :)
>> So the feedback was good.
>
> I think so. Andreas, what is your opinion about the new design? Do you
> still think there are two much traits for a too small benefit?

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

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.

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.

Cheers,
   - Andreas

Hi Andreas,

2007/11/9, Andreas Raab <[hidden email]>:
> 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

but you could not reuse code for the backward compatible version.
But I know you do not like traits and this is your right.
having a good browser is definitively needed.