Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!psuvax1!rutgers!mcnc!rti!sheol!throopw
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.c++
Subject: Re: asking an object for its type
Message-ID: <1190@sheol.UUCP>
Date: 15 Feb 91 21:35:23 GMT
References: <23984@netcom.COM>
Lines: 22

> aed@netcom.COM (Andrew Davidson) 
> I have some processing that only applies for certain types of objects. 
> If an object is not of the correct type I want to do some error stuff. 
> The problem is how do I fiqure out what the type of the object is. 

I don't know the full context of this, but from this fragment it seems
that testing the type of an object to decide what to do with it is
wrong-headed from the very start from an object oriented perspective. 

Isn't a large part of the benefit of the OO idea the avoidance of all
the "if"ing and "case"ing and "select"ing that goes on when algorithms
are divorced from the data they manipulate?

So, shouldn't the solution be to simply perform the operation on ALL the
objects, and arrange for the ones to which it doesn't apply to treat it
as a NOP?  And, if necessary, supplying a derived or containing class (or
rather, classes) to arrange for this if it isn't reasonable to add these
operations to the original class(es)?

As I said, I may be missing some context, but that's the way it seems to me.
--
Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org