Hi Nathanael,

I just wanted to add my opinion to the discussion:

My first reaction was that I am totally in favour of including your
changes. I looked at all the senders of #respondsTo:. There are 125 of
them in my image. I looked at about 20 of them and *all* of them had the
following pattern:

(anObject respondsTo: #initialize) ifTrue: [anObject initialize]

For me this clearly indicates that a developer using #respondsTo: in
this way assumes that (s)he can savely call the selector without getting
a debugger. I consider the old behaviour to be an outright bug. And it
is not problematic to change the semantic of buggy methods, quite on the
contrary. I am sure the image will be more robust with the proposed
change.

Then I looked at the senders of #canUnderstand:. There are only 14 of
them in my image and there are two differen usage patterns:

(anObject class canUnderstand: #asMorph) ifTrue: [anObject asMorph]

The second pattern looks like this:

(aClass canUnderstand: #someSelector) ifFalse: [
	self compile: #someSelector]

The first pattern should be rewritten using #respondsTo: anyway. Then
only the second pattern remains. And these should not use the new
semantic IMO. Because then the marker methods might get recompiled and
the marker information is lost. That would be a Very Bad Thing, don't
you think so?

So my conclusion: Change the (currently buggy) semantics of
#respondsTo:, rewrite the first usage pattern of #canUnderstand: with
#respondsTo: and do not change the semantic of #canUnderstand:.

(Another interesting but totally different discussion: I do not like
#respondsTo: very much in the first place. I am almost sure some senders
could be redesigned so that they do not need it anymore.)

By the way, many thanks for your work! I am really looking forward to a
Traits package that I can load in a current Squeak image!

- Bernhard