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