Joel Shellman <joel at ikestrel.com> came up with another
"let's see how complicated we can make it instead of a simple
message send" proposal:

	Processor>>process: anObject
	    [
	        anObject isFoo
	          ifTrue: [ Transcript show: 'Do the necessary processing'. ]
	          ifFalse: [ Transcript show: 'Do nothing'. ]
	    ]
	    on: MessageNotUnderstood
	    do: [
	        Transcript show: 'Could not process object so do nothing.'.
	    ]
	
Horrible.

	

May I remind readers that there are 18 #isFoo messages in Object,
that half or more of them refer to "core" classes like Number or Stream,
and that 2 or 3 of them would be quite easy to eliminate.

I really don't see anything evil about Object>>isNumber or Object>>isString;
numbers and strings are core parts of the language and it seems fair enough
for an object to know it isn't one.

I *do* think that requiring people to write

    ([anObject isNumber] on: MessageNotUnderstood do: [false])
        ifTrue: [handle number]
        ifFalse: [handle anything else]

instead of just plain

    anObject isNumber
        ifTrue: [handle number]
        ifFalse: [handle anything else]

is (let me be tactful here) seriously misguided.
        
It would be especially misguided when you are using an #isFoo method
that is *not* defined in Object, so that a DNU would represent an
actual error that you would definitely want to be told about!

I would have to call this an abuse of the exception handling machinery.

By all means, let's try very hard not to add methods to Object if we can
avoid it.  But the present set of #isFoo messsages in Object are pretty
harmless.  They are certainly far less destructive of clarity and good
practice than all the alternatives that have been suggested.