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

Klaus D. Witzel klaus.witzel at cobss.com
Fri Mar 2 09:04:21 UTC 2007


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




More information about the Squeak-dev mailing list