Newsgroups: comp.lang.c++
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Subject: Re: asking an object for its type
Message-ID: <1991Feb19.000449.22255@gpu.utcs.utoronto.ca>
Organization: Craig Hubley & Associates
References: <23984@netcom.COM> <1190@sheol.UUCP>
Date: Tue, 19 Feb 1991 00:04:49 GMT

In article <1190@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
>> 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. 

"objectively" one would have an error-handling routine that would do
nothing for objects of the correct type, and something else for objects
of other types.  However, error-handling is typically far more context-
dependent, and the main idea of O-O is to keep objects context-free and
exclude non-portable, non-reusable details like how to respond to an
application-specific problem.  

That is why most O-O languages (probably all by now) incorporate a separate
error-handling mechanism.

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

Yes, this is a large part of being context-free, but in cases where the
algorithm is application-dependent, you DON'T want parts of it seeping into
your objects.  As I pointed out, error-handling is one such situation, but
imagine a database query:

	"from the list of shapes, show me all the circles of diameter > 30"

Arg.  A totally contextual algorithm.  I do NOT want to write a special
function for all shapes to respond to this.  What I would really like to
do is something like:
	"if x.type=circle then if x.diameter > 30 then return x"

But without a type tag, I can't even check if there IS a diameter!  Arg!
So I write my own type tag, incompatible with everyone else's, or risk 
errors.  But in more intelligent O-O languages, asking the type, or better,
asking if there is a diameter, is a fundamental operation in type Object
that all objects can do.

>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)?

This was the solution I refuted above.  In C++ you can often define free
overloaded functions to deal with such contextual cases in an application,
and make up for the fact that the predefined classes don't deal with them.
But it's a mess, subject to combinatorial explosion and constant rewriting
of your classes.  And most O-O languages don't do it that way.

>As I said, I may be missing some context, but that's the way it seems to me.

And to most people, until they recognize some of the limits of having only
one simple polymorphism mechanism.  C++ has several (overloading, conversion,
virtuals, templates) but it doesn't co-ordinate 'em very well.

>Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org

-- 
  Craig Hubley   "...get rid of a man as soon as he thinks himself an expert."
  Craig Hubley & Associates------------------------------------Henry Ford Sr.
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig