Hi stef,

on Fri, 02 Mar 2007 21:07:24 +0100, you wrote:
> On 2 mars 07, at 10:04, Klaus D. Witzel wrote:
>
>> Fellow traiteurs :)
>>
>> I wonder why the heck a plain Behavior, especially one which doesn't  
>> want to have/refuses to know about traits, is required to provide for  
>> the messages mentioned in the subject line.
>
> I understand but we do not have behavior with and without traits so what  
> would be the solution.

Any solution which would not _force_ *every* possible (ancient or future)  
subclass of Behavior to be traits-laden would be a solution.

> Have subclasses that may not implement these methods and if they are  
> used in traits would break because they did not implement
> the messages.

A class cannot be composed into a traits so, nothing can break. The other  
way around: yes. Or, what did you mean?

> May be this is the solution. I think that adrian put  
> subclassResponsibility to express that a class to have traits requires
> to have these three messages implemented.

Sure. With emphasis on *class*, but (Behavior ~= Class).

>> Doesn't that add to the complexity of the Squeak traits implementation  
>> (which often receives negative critique here in squeak-dev).
>
> Come one do not play it like that....

Facing reality is not a game, stef. But, you know, there's a way to avoid  
such comments.

>> I suggest to consider changing that, either by replacing these  
>> #subclassResponsibility with neutral values and actions,
>
> what would they be. I always prefer default value over abstract method.

The implementors of those three suggest default values like:

hasTraitComposition ^ false

traitComposition: anObject ^ self error: 'I told you above that I have no  
traits composition'

traitComposition ^ self error: 'I told you above that I have no traits  
composition'

Any other, perhaps more clever way would do.

>> or by moving traits requirements out of the way of plain Behavior.
>
> But in that case this means that we do not document a part of the  
> required protocol in case of traits use.

I did not say *delete* them and (move ~= delete).

>> The way it is now forces new subclasses of Behavior to implement these  
>> requirements (something which I came across when filing in pre-traits  
>> source code). I do not refer to new classes made with ClassBuilder, but  
>> instead
>>
>>  (Behavior basicNew superclass: Behavior
>> 	methodDictionary: (MethodDictionary new)
>> 	format: Behavior format)
>
> I know this one. It is cool that now it works.

Is it possible that either you or I is missing something. This expression  
does *not* work, it raises #subclassResponsibility b/o traits.

>> Moreover, after providing for #subclassResponsibility, the code will  
>> then have parts which make no sense in non-traitified images.
>>
>> I understand that many factors of traits have a nice home on the  
>> instance side of Behavior, but wouldn't a subclass also fit the bill.
>
> Do you mean that we could have a subclass BehaviorWithTraits because  
> this would keep Behavior untouched and still introduce the
> traits with subclassResp notification for abstract methods.

Yes, that is a possibility. But the default values from above can work  
regardless of subclassing, so there is choice what to do with the issue.

/Klaus

> Stef
>>
>> TIA.
>>
>> /Klaus
>>
>>
>>
>
>
>