Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: asking an object for its type
Message-ID: <71034@microsoft.UUCP>
Date: 4 Mar 91 20:20:49 GMT
References: <23984@netcom.COM> <1190@sheol.UUCP> <70902@microsoft.UUCP> <6900@mace.cc.purdue.edu>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 55

In article <6900@mace.cc.purdue.edu> nvi@mace.cc.purdue.edu (Charles C. Allen) writes:
|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.

One of the original authors suggested that what was being proposed was
a way to test whether an object supported an individual method or not.
He then went to to argue way such support is bad.  I counter-argued
that what is really needed is neither the ability to test whether an 
object supports some particular method, nor the ability to test whether
an object is some exact type, but rather, what is needed is the ability
to test whether an object supports some particular protocol. 

|> 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.

I did not mean to imply that Smalltalk can't do this.  I meant to imply
that Smalltalk also supports exact type testing, and even worse, supports
testing whether or not an object has a particularly named method.
I agree that using such overly restrictive tests is bad and greatly 
restricts code reuse.  But, I is disagree that because supports-
method testing and exact-type testing are bad means we should not support
*any* notion of run-time type testing in C++.  On the contrary, in C++
one needs to know if a particular unidentified objects supports a
particular protocol before you can do something reasonable with it.
I think its quite reasonable to have objects in a context where they
do not have support the necessary protocols to be used in that context -- 
it just means that the object cannot be accessed via that context.

A silly example might be that of an IC-layout program.  The database of
objects may include things that are displayable, but which are not
editable via the IC protocol.  We'd still like to be able to include
such objects in the database, and display them on the schematic diagram.
But you wouldn't be able to edit them using the IC-editor -- since they
don't support the IC protocol.  Such objects presumably support a 
displayable-object protocol, but do not support an IC protocol.