nicolas cellier wrote:
> Seems like I missed the interesting point.

And I don't think you got it now either ;-) My point was that over time 
fundamental assumptions can change and that for a widely reused behavior 
  it will be very difficult to change fundamental assumptions, resulting 
in the necessity to use overrides to represent changed understanding. It 
seems unavoidable. You see this in Squeak for example in the overrides 
of ReadStream and PositionableStream and my conclusion was that although 
Nile can do without those right now I am not certain it would stay that 
way in the long term; in particular for situations where it is easy to 
argue either way.

> What would be the single inheritance scheme? Provide some kind of 
> pluggable behaviour with additional inst vars like an 
> objectToReturnWhenAtEndOfStream or a blockToExecuteWhenAtEndOfStream?

This has nothing to do with inheritance schemes. Overrides exist in both.

> Your proposing to override when the logic would be to fragment in more 
> traits.
> 
> It seems appealing to construct a custom stream from traits composition: 
> Readable , AnswerNilAtEndOFStream , CanStepOneObjectBack (Peekable).
> But I agree that the price seems high (leads to greater fragmentation of 
> code with distributed constraints, or in other words less encapsulation 
> and more interfaces).

I think you meant appalling not appealing ;-)

Cheers,
   - Andreas