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: <1991Mar8.073356.25207@gpu.utcs.utoronto.ca>
Organization: Craig Hubley & Associates
References: <1991Feb20.232710.7843@ithaca.uucp> <1485@acf5.NYU.EDU> <71037@microsoft.UUCP> <27D57565.2B22@tct.uucp>
Date: Fri, 8 Mar 1991 07:33:56 GMT

In article <27D57565.2B22@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to jimad@microsoft.UUCP (Jim ADCOCK):
>>C++ should actively support runtime type testing because the issue keeps
>>coming up again and again and it takes great difficulty for individual 
>>applications to create it for themselves.  
>...
>Lots of Smalltalk, Objective C, CLOS, etc. programmers are converting
>to C++, and they are looking for language features like those of their
>previous languages so they can keep programming in the ways to which
>they are accustomed.  This fact is not surprising.

Yeah, lots of C programmers would be upset if such dangerous anachronisms
as public data members went away, too.  Problem is, people who are already
using these other OO languages are already building reusable code libraries,
and there is comparatively less experience with building such libraries in
C++.  We might want to listen to them tell us what they need.  Especially
if the only answer on "how to do it" coming from the C++ community is
"add it as a virtual in the base class".  I agree with the author who
called this "laughable".  From the perspective of binary-reusable libraries,
anyway.

>What they do not realize, however, is that C++ programming does not
>always admit of Smalltalk/Objective C/CLOS/etc. strategy.  Some of
>them eventually get a clue.  Many, however, never give up in trying to
>force the square C++ peg into the round dynamic-type-test hole.

Since C++ is the production language of choice for those building PROTOTYPES
in Smalltalk and CLOS, at least, allowing easy conversion of components
between these languages and C++ is an ongoing problem.  Potentially one of
great industrial importance, if prototyping this ways becomes more widespread.
I see it happening in dozens of organizations right now...

>>The implication being that run-time type testing requires an interpreter-
>>like approach, or that adding run-time type testing turns C++ into 
>>a Smalltalk or a CLOS.  I disagree.
>
>It would not transform C++ into Smalltalk, true.  But it would be a
>move in that direction, a move which is, in my opinion, entirely
>unnecessary.

But you probably don't prototype in Smalltalk and then ship in C++.  And
you didn't learn Smalltalk in school and now have to learn C++.  And you
have already said you don't believe much in binary-reusable libraries, or
at least their usefulness in what you do.  IMHO:

Such opposition appears to be political:  you don't want the language
"hijacked" by "outsiders" by which you appear to mean people who aren't
doing everything in C and liking it.  I can understand why you won't
accept arguments like "it's done that way in Smalltalk", but ANSI is
not supposed to accomodate C programmers, it is supposed to cut costly
re-invention and re-education (of/in things that should be standardized
but aren't) for all of US industry.  Prototyping in other OO languages
and shipping in C++ is a fact of life.  So is the preference for "pure"
over "hybrid" languages in education.  So is the desire for (and corporate
commitment to) extend class hierachies without source access.  At least a
lot of firms are planning to waste big money trying, if waste it is.

Given all these facts, it is a mighty big $ argument for making the change.
So I don't see how political (i.e. interest-group) arguments can do anything
but sanctify the "move towards Smalltalk", as you put it.  There is a huge $
payoff for doing so, or at least many companies believe there is, or they
wouldn't be interested in object-oriented systems (or possibly C++) at all.
So please, let's continue this argument along technical grounds.

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