On Wednesday 10 October 2001 06:14 pm, you wrote:
> ...snipped good points from others...
>
> Another thing to consider, Eddie, is that #isKindOf: on most Smalltalks
> refers not only to the class you are checking, but also to it subclasses.
> This may or may not be what you're after.
>
> For example, if I create a class Human, with two subclasses, Chris and
> Eddie, then asking some object #isKindOf: Human may make sense for Eddie,
> but perhaps not for Chris (this distinction is probably debatable).
>
> In any case, I wanted to chime in and agree that general use of #isKindOf:
> should be limited.  Not only is it a more time consuming operation (its got
> to check all those subclasses, after all), but it also implies that you are
> not really too sure what kind of object you're dealing with and that is
> rarely a good thing.
>
> You should strive to provide polymorphic methods for the classes you
> expect. Classes that do not support to the interface you've defined for
> your component are undoubtedly unfinished.
>
> Cheers,
>
> ---==> Chris

	Well, this is really is the type of problem that interfaces were designed to 
solve in Java. Or at least, could solve in smalltalk.

	Lets I define a interface called "Baz" that contains the messages foo:bar: 
and foo:

	Currently, If I want to know if a object knows all the messages for a given 
class/subclass I have to ask.

	respondsTo:#foo:bar:
	respondsTo:#foo: 
	etc etc for however much I need to be certain.

	If I use one message, it's almost guaranteed I may need to use other related 
messages too.

	Or I have to ask it isKindOf: which is intensive

	With interfaces, I could say "implementsInterface"

	This catches cases were disparate classes may implement a useful interface 
that I couldn't test with isKindOf:

	I mean, if class A inherits from B, and Class D intherits from C, asking 
class C isKindOf:A won't tell me if C understands B messages. They're not on 
the same subtrees.

	Course, in Java, interfaces were really created to get around the strong 
typing of the Language, but they also allow spreading common messages across 
classes. Smalltalk has no typing. So perhaps, we should call them 
'protocols', because really, essentially what matters is that a class 
understands a certain message, or groups of messages. 

	So we could say have...

	Bar Subclass: #Foo ImplementsProtocols: { Baz, Qux, Faz }

	Deg Subclass: #Wozzle ImplementsProtocols: { Baz, Zoig, Bip }

	This is not necessarily correct, I'm just giving the gist here.

	And Deg and Bar could be in seperate unrelated subtrees, but would reply....

	Bar SpeaksProtocol: #Baz would be true
	Deg SpeaksProtocol: #Baz would be true also.

	Then, we get the following....

	We could have StringProtocol, NumberProtocol, Etc etc.  DragNDropProtocol, 
etc etc.

	Because, if you use one message, you'll often use the other related messages 
too.

	Basically, It's the same idea in SmallInterfaces, but I like the name 
protocol better. This implies a group of related messages, and messages are 
what matter in ST.


	Daniel Joyce