Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!mace.cc.purdue.edu!nvi
From: nvi@mace.cc.purdue.edu (Charles C. Allen)
Newsgroups: comp.lang.c++
Subject: Re: asking an object for its type
Message-ID: <6900@mace.cc.purdue.edu>
Date: 27 Feb 91 14:21:32 GMT
References: <23984@netcom.COM> <1190@sheol.UUCP> <70902@microsoft.UUCP>
Organization: Purdue University
Lines: 30

In article <70902@microsoft.UUCP>, jimad@microsoft.UUCP (Jim ADCOCK) writes:
> Smalltalk, C++ doesn't match methods based on name anyway.  Two independent
> classes can both have a member "doSomething()" and the name matching
> could be totally accidental, and mean totally different things, and
> the two authors of those independent classes may have absolutely no
> intention that their two classes be intermixed.  We don't want to reinvent
> the Smalltalk situation where accidental matching of methods occur.

Perhaps you could explain the exact problem here.  I agree that two
"doSomething" methods can mean different things, I just don't
understand the problem in the context of this discussion.

> Since protocols are inherited from some base class, some people conceptualize
> this slightly differently:
> 
> 	if (unidentifiedDeserializingObject->IsSomeSubClassOf(Class("FooBar")))
> 	{
> 		doFooBarThingsWith(unidentifiedDeserializingObject);
> 	}

You seem to imply that Smalltalk cannot do this.  Smalltalk knows both
the class of any given object and the class hierarchy, so it can
certainly determine whether or not an object is "a kind of" FooBar:

	anObject isKindOf: Foobar.

Charles Allen                           Internet: cca@physics.purdue.edu
Department of Physics                   HEPnet:   purdnu::allen, fnal::cca
Purdue University                       Bitnet:   cca@fnal.bitnet
1396 Physics Building
West Lafayette, IN  47907-1396          talknet:  317/494-9776