Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!csc.ti.com!ti-csl!tilde.csc.ti.com!choctaw!peterson
From: peterson@choctaw.csc.ti.com (Bob Peterson)
Newsgroups: comp.std.c++
Subject: Re: type/member tags (was Re: asking an object for its type)
Message-ID: <1991Mar11.140348.10545@csc.ti.com>
Date: 11 Mar 91 14:03:48 GMT
References: <27CD159D.6581@tct.uucp> <1991Mar5.143615.5847@csc.ti.com> <71091@microsoft.UUCP>
Sender: usenet@csc.ti.com (USENET News System)
Organization: TI Computer Science Center, Dallas
Lines: 55
Nntp-Posting-Host: choctaw

In article <71091@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>In article <1991Mar5.143615.5847@csc.ti.com> peterson@choctaw.csc.ti.com (Bob Peterson) writes:
>|  I see the need for a standard mechanism for accessing a class
>|instance's type.  I believe a general mechanism, similar in spirit to
>|the property lists found in Lisp, would support not only type
>|information, but the needs of other enhanced facilities such as
>|programming environments.  I'd like to see the compiler insert into
>|each class a static member function that returns a pointer to a singly
>|linked list of pointers to a class instance.  The class pointed to
>|would have defined only a virtual function returning a descriptor.  The
>|descriptor would describe the sort of information the actual instance
>|contained, e.g., a description of a type.  Users would be able to
>|derive from the language-specified class description expanded classes
>
>....
>
>Seems we're getting hung up arguing details of compiler implementation
>rather than issues of language definition.  How should run-time
>type information be represented in the language -- as opposed to in the
>resulting executable? 

  Sorry, I misspoke.  My phrasing above, using the word "compiler,"
mislead you.  

  I intended to suggest the _language_ be enhanced to require a
conforming language processor to predefine in each class a static
member function, which returns the list described above.  Also added
would be a predefined interface through which a user program could add
application-specific elements onto the list.  The language would
predefine some descriptor values, reserve additional values for future
enhancements, and reserve a range of values for user-defined (and
nonstandard) functionality.  Similarly, a conforming language processor
would be required to implement certain descriptors, and would be
generate others based on user-specified options, i.e., when the user
asks for them.

  The spirit of my suggestion was along the lines John Interrante and
Mark Linton suggests in their "Runtime Access to Type Information in
C++" paper (in the Proceedings of the 1990 USENIX C++ Conference, pp.
233-240).  The paper describes "Dossier," and experimental experience
using the idea in Interviews' Unidraw library.

  However, I would like to extend the idea to cover a variety of future
needs, not just the single idea of runtime type information.  In
effect, I want an extensible mechanism able to supply a variety of
metaclass information.  I also suggest defining a static function,
rather than a member variable, for additional flexibility, and to avoid
the "sometimes it is virtual, other times not" suggestion made in the
above paper.

    Bob
Bob Peterson                Compuserve: 70235,326          Expressway Site,
Texas Instruments           Internet: peterson@csc.ti.com   North Building,
P.O. Box 655474, MS238      Landline: (214) 995-6080         2nd Floor,
Dallas, Texas, USA 75265                                      CSC Aisle C3