On Wed, 28 May 2003 22:05:44 -0700, Joel Shellman <joel at ikestrel.com> 
wrote:

> However, that same distinction can be made for any class: 1) is an 
> instance of MyClass, 2) is not an instance of MyClass.

Firstly, #isFoo should not be about any particular class. It should be
about the behavioral protocol supported by a receiver of #isFoo.  To care
about the class of an object violates encapsulation.

Secondly, the number of methods that might legitimately be added to any 
class is probably infinite (at least for many classes, if not for all 
classes.)
The same holds for the number of classes that might legitimately be 
defined.  Obviously, actually adding every conceivably legitimate class to 
the system, or every conceivably legitimate method to a class, would not be 
a good idea.

It is wrong to single out a single design principle and apply it 
indiscriminately, without also considering other design principles.

If the question is whether or not adding an #isFoo method to Object is
a priori a violation of good design principles--specifically, the principle
that classes should only have methods whose domain naturally includes or
involves instances of the class--then the answer is an unequivocal no.  
Howerver,
if the question is whether or not adding an #isFoo method to Object is 
always
justified, after fully considering all design principles, the answer is 
also an unequivocal no.

I would not add an #isFoo method just to distinguish between any two 
classes.

I would not add an #isFoo method in the absence of any proven need to write
code that was conditional on whether or not an object was type-compatible 
with the protocol Foo.

I would not add an #isFoo method if there were some better way to 
accomplish
my objectives, such as delegating the responsibility for the protocol- 
conditional
logic to the object itself, instead of asking the object whether or not it
conforms to Foo protocol. Another often-useful tactic is to avoid putting
objects with different protocols in the same variables, collections or 
streams,
unless those protocol differences are always irrelevant in all cases where
messages are sent to the objects involved.  Usually, objects with different
protocols play different roles--and the fundamental purpose of variables is 
to distinguish one role from another.

I would prefer to use #conformsToProtocol: as the general mechanism for 
discovering
whether or not any object conforms to any particular protocol, and reserve 
#isFoo
for the most commonly used cases (because of the speed advantage.)

--Alan

-- 
The Stupid Party thinks everyone else is evil.  The Evil Party thinks 
everyone else is stupid.