Andreas Raab a écrit :
> 
> I mean that some of the basics of the Squeak stream hierarchy got put 
> into place some twenty years ago and some assumptions simply changed 
> over time. I would expect the same to be true for Nile, in particular if 
> the quantitative reuse of traits is higher. For example, consider that a 
> trait defines an operation that raises an exception (#next anyone? ;-) 
> and that five years later you figured you were wrong and that you'd 
> rather have it silently return nil. Can you fix that at this point? 
> Seems *very* unlikely if those traits are widely used. So what happens 
> is that every "new" user of that trait will start overwriting the method 
> so you get into precisely the same situation as with the current 
> collection hierarchy. It seems unavoidable in the long term that some of 
> these issues will happen (and yes, "in theory" all of that is fixable 
> but I'm talking about a practical situation).
> 
> Cheers,
>   - Andreas
> 


Hello Andreas,
If you insist on it, yes, I must agree that answering nil at the end of 
a Character Stream is a good trade-off and a simple lightweight 
implementation.
(Due to low cost of == nil, Exception becomes faster only for large files).
But, it is also a very dumb thing to do with generic Streams of Objects:

Collection allSubInstances count: [:e | [e includes: nil] ifError: [false]].

My image counts 16785 such nil holders...

Cheers