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