Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ithaca!garry
From: garry@ithaca.uucp (Garry Wiegand)
Newsgroups: comp.lang.c++
Subject: Re: asking an object for its type
Message-ID: <1991Feb20.232710.7843@ithaca.uucp>
Date: 20 Feb 91 23:27:10 GMT
Organization: Ithaca Software
Lines: 69

sdm@cs.brown.edu (Scott Meyers) writes:
>In article <607@taumet.com> steve@taumet.com (Stephen Clamage) writes:
>| All you have to do is make a virtual function diameter() for all Shapes.
>
>    class Arc { ... };
>    class ControlArc: public Arc { ... };
>    class DataArc: public Arc { ... };
>    class NPControlArc: public ControlArc { ... };
>
>...  How can they do this if all they have is a set of Arc pointers?  In
>this case, I could provide a virtual function called draw, but in general
>an application might want to do something I've never heard of, so there
>will be no virtual function for them to call.  That being the case, there
>needs to be a way to find out the "real" type of the Arc pointer, so they
>can do the appropriate thing.

This "isKindOf" argument keeps coming up. Perhaps the problem should
be attacked the other way: what would it take to allow an application 
to add a virtual function to an existing class (for which the
application programmer doesn't have source)?

First thoughts:

A) Allow "change type of". The application can now derive a new class 
   from each library class and add its virtual function. If the
   application does all of the instance-creating, and only creates
   derived objects, things work out. *But* if the library creates one
   of the instances, the instance's virtual function table won't be the
   one the application wants. 

   So: allow some syntax for an base class instance to be *actually
   changed* into a derived class instance. Doesn't work if the derived
   class requires extra instance variables (can't change the size
   without considerable trickiness). *Does* work (the v-table pointer
   is switched) for extra virtual functions. 

   (The symmetric operation (derived class to actual base class) should
    also be legal, but right now I don't see the utility.)
   
B) Never use "new" in a library. Always allow the application to
   do the allocating, thereby avoiding the problems with "if the
   library creates an instance". This can be implemented with the
   current C++.

   This could be made formal with syntax of the form "for the duration
   of this block, please override the constructor of class foo".
   (Even more generally, allow a class itself to be passed in as an
   argument -- promote classes to first-class objects. Eek -
   Smalltalk!) 

C) Continuing the train of thought, back in C++-land, allow "class 
   augmentation" at least for virtual functions. This means loosening
   the requirement that all modules agree exactly on the declaration of
   a class. In particular, allow the v-table to grow to allow a limited
   run-time binding of virtual functions. Virtual functions known at
   compile-time of the constructor of the class would work as now. A
   new mechanism would be implemented to allow other modules to
   incorporate in their own "deferred" virtual functions for that class
   during their own initialization; functions that the constructor
   module didn't know about. 

   I can think of several methods of implementation, all of them great
   fun :-). The more general case of allowing instance functions AND
   instance variables to be added to the class is also do-able.

D) I don't have a D). Suggestions?

Garry Wiegand    ---    Ithaca Software, Alameda, California
...!uunet!ithaca!garry, garry%ithaca.uucp@uunet.uu.net