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
|