Andreas Raab a écrit :
> 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.
> 

Yes, and after 2 or 3 overrides, the code rots and stinks enough that a 
complete refactoring is wanted (every user of Squeak should have his own 
example in mind)... eventually leading to these traits questions...

It's quite impossible to answer whether traits would defer the need for 
overriding or not on fair basis...

If implementation is more complex, it could eventually be broken faster 
by unaware code maintainers and rot faster...

>> 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.
> 

For something core like the #next example, overriding is hardly an 
option, because you have to override several Stream branches and some 
#next senders too. Thats why i bounced on composition, but seems like 
nicolas interest does not match Andreas interest.

>> 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 ;-)
> 

Thanks for teaching me some ugly words, that was funny (and easy too).

My point was to question about multiple inheritance pros, and 
composition is IMO the one that could justify Nile attempt.
Sure, in simple inheritance world i have other solutions like pluggable 
behaviour, composition by inst var, stream wrappers...
I don't expect a response, I already know and respect your opinion. I 
feel like I'd better try by myself to forge my own.

Cheers