Behavior and #subclassResponsibility of {#hasTraitComposition. #traitComposition:. #traitComposition}

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.

Doesn't that add to the complexity of the Squeak traits implementation  
(which often receives negative critique here in squeak-dev).

I suggest to consider changing that, either by replacing these  
#subclassResponsibility with neutral values and actions, or by moving  
traits requirements out of the way of plain Behavior.

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)

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.

TIA.

/Klaus

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.
Have subclasses that may not implement these methods and if they are  
used in traits would break because they did not implement
the messages. 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.

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

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

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

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

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

Hi stef,

on Fri, 02 Mar 2007 21:07:24 +0100, you wrote:
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).

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