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

stephane ducasse stephane.ducasse at free.fr
Fri Mar 2 20:07:24 UTC 2007


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




More information about the Squeak-dev mailing list