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