Doug Edmunds wrote:
> Squeak 3.9 #7067
> 
> I happened to be comparing Squeak to Dolphin CE, and ran across
> this bug in Squeak relating to respondsTo:
> 
> (3 @ 4) respondsTo: #<=.  "Squeak reports this as false"

I tried this exactly as written here and Squeak 3.9 7067 reports this 
correctly as true. I think you might have tried, e.g.,

   Point respondsTo: #<=.

(since you are using this below for other supposedly wrong results).
Basically, what you are missing is the distinction between instances and 
classes - if you ask an *instance* of Point, like "3 at 4" whether it 
responds to #<= it will say yes, but if you ask the *class* Point it 
will answer no, because in fact, *class* Point does not respond to #x.

> Trying other methods for Point, I get many similar 'false' results when
> sending 'respondsTo:' to Point (but I also get many correct results).
> 
> ie.
> 
> Point respondsTo: #abs.  "false"
> however,
> Point respondsTo: #hash.   "true"
> Point respondsTo: #storeOn:.  true

The reason these answer true is that all objects (incl. class Point) 
respond to these messages - even nil, the UndefinedObject.

> Point respondsTo: #x. false
> but
> (3 @ 4) x. "3"

Absolutely. The Point *class* does not respondTo: the message but the 
Point *instance* does. If you want to know whether a class can 
understand a particular message then you should ask for that, e.g.,

(3 at 4) respondsTo: #x. "=> true"
Point respondsTo: #x. "=> false"

However,

Point canUnderstand: #x. "=> true"

The duality of #respondsTo: and #canUnderstand: exists because classes 
are objects, too, and therefore answering true to "Point respondsTo: #x" 
would be plain wrong since class Point does indeed not respond to #x.

> Point respondsTo: #y. false
> but
> (3 @ 4) y. "4"
> 
> There does not seem to be any pattern to when
> respondsTo: works correctly and when it doesn't.

Oh, yes, there is. If you ask an *instance* use #respondsTo:. If you ask 
the *class* use #canUnderstand:.

Cheers,
   - Andreas