Path: utzoo!utgpu!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: <70902@microsoft.UUCP>
Date: 26 Feb 91 18:10:23 GMT
References: <23984@netcom.COM> <1190@sheol.UUCP> <1991Feb19.000449.22255@gpu.utcs.utoronto.ca> <607@taumet.com> <65451@brunix.UUCP> <11284@pasteur.Berkeley.EDU> <1991Feb21.182349.19132@gpu.utcs.utoronto.ca>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 59

In article <1991Feb21.182349.19132@gpu.utcs.utoronto.ca> craig@gpu.utcs.utoronto.ca (Craig Hubley) writes:
|In article <11284@pasteur.Berkeley.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes:
....
|>Why?  Because people will add new types of Arcs and you won't deal with
|>them properly.  You're dealing with objects based on an exact match of
|>some type string instead of based on some relevant attribute that a
|>virtual function could return.  You're wiring in a list of classes you
|>can handle, requiring more code rewriting as classes are added.
|
|Right on.  This why a simple typeof() won't do either.  It is possible
|to build a more consistent way to tell what an object can really do,
|(e.g. x.hasmember("diameter")) but this is only marginally better since
|you are still requiring code to be rewritten and deal with the names,
|which you supposedly already dealt with in the class header.

You guys are arguing against bad implementations, not a bad idea.

One doesn't want to test against an exact type as Joe points out,
since one then cuts off the possibility of using polymorphism and 
further derived classes.

One doesn't want to test against an exact member match as Craig points out,
because then you're dealing with individual member names, and, unlike
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.

What we do want however, and what does make sense [IMHO :-] is to be able
to test for "protocol" -- to see if a particular object matches a particular
protocol.  A "protocol" being the a set of methods that are matched --
which is the C++ concept, verses single method matching ala Smalltalk.
So, given an otherwise unidentified object -- perhaps an object one is
deserializing, one might want to ask:  "Does this object respond to 
the foobar protocol, in which case maybe I want to allow access to this
object as-if a foobar?"  In C++, then, in order to be able to communicate
to an object, you need to be able to ask questions about its protocol.
A suitable method name might be a virtual IsSomeKindOf(Protocol):

	if (unidentifiedDeserializingObject->IsSomeKindOf(Protocol("FooBar")))
	{
		doFooBarThingsWith(unidentifiedDeserializingObject);
	}

Since protocols are inherited from some base class, some people conceptualize
this slightly differently:

	if (unidentifiedDeserializingObject->IsSomeSubClassOf(Class("FooBar")))
	{
		doFooBarThingsWith(unidentifiedDeserializingObject);
	}

[In the above examples I immediately cast away from the "FooBar" strings lest
 anyone make the mistake to think I am suggesting that strings are the
 right way to represent such information.  Ideally, one should be able
 to directly use a subclass name, rather than a string representation of
 that name, or some other additional/incompatible representation.]