[ I posted a somewhat article with emphasis on persistant storage
  products to comp.lang.c++.  It occurs to me that some of these issues
  might be worth kicking about in the "standards" group.  If you're
  running a threaded newsreader, this article references the other one. ]

Has anybody given thought to adopting standards for the sort of operations
one does on objects to support "streaming" them to and from persistent
storage?  All of these things can be done via one's own mechanisms, of
course, but some of them might be worth addressing in a generic fashion:

A standard way of "serializing" or "linearizing" an object instantiation,
that is, obtaining the flattened list of objects ultimately pointed to
by a particular instantiation of a top level object.  Logically, this could
be something controlled and called in appropriate heirachical fashion
by the compiler, as are constructors / destructors.  For full versatility,
the language would probably define it using a callback mechanism, and thinking
of it as a "visit" operation where the visitation method may in turn visit
the things it points to, if not already visited, descending through all the
classes much as it handles destructors which may delete objects they point
to.  In fact, since the visit mechanism would include some way of figuring out
whether an item had been visited or not, you could use this to DO your
destructors, and not have to handle circularities specially to avoid
an infinite recursion of delete's.

The actual methods by which objects "write" or "read" their attributes is
probably hard to make into a general language mechanism, but perhaps worth
thinking about.  Certainly, as "standard" base class libraries evolve, a
standard storage object might be called for.

I haven't been paying as close attention to the RTTI proposals as I probably
ought to have - one thing that would be needed here is a way to get at
some sort of class descriptor as an object in it's own right, and be able to
parameterize that thing for programmatic manipulation, and persistant storage
itself.  To restore things from persistant storage, you have the following
problems, which seem to touch on RTTI:

 1) Need to create a default object of an arbitrary type not known
    at compile time, in order to tell it to start rebuilding itself
    from stream storage.

 2) To be intelligent about it, and support some sort of versioning
    concept, the persistent storage mechanism probably wants to
    retain information concerning the inheritance heirarchy which
    applied to a particular class when it was stored - allows
    modifications to the heirarchy to be handled, and/or produce
    errors when there are conflicts without versions having changed.
    I am very much thinking of the version as an attribute of the
    class descriptor - changes in heirarchy as well as object
    attributes could be reflected through versioning, and different
    versions could have different inheritance DAG's with no conflict.

 3) To relieve the burden on "read" methods with respect to knowing
    their heirarchy for particular versions, the ability to access
    a particular method on an object, not by directly naming it at
    compile time, but indirectly through a class description would
    help.

What I think of as coming under the RTTI set of features seems to me to be
the most important extension needed to C++ - the one thing that EVERYBODY
is winding up simply implementing for themselves, especially if they wish
to design some sort of "metatool" which manipulates class definitions.

In article <1993Jun2.213757.15698@pony.Ingres.COM> bobm@Ingres.COM (Bob McQueer) writes:

 >A standard way of "serializing" or "linearizing" an object instantiation,
 >that is, obtaining the flattened list of objects ultimately pointed to
 >by a particular instantiation of a top level object.  Logically, this could
 >be something controlled and called in appropriate heirachical fashion
 >by the compiler, as are constructors / destructors.  For full versatility,
 >the language would probably define it using a callback mechanism, and thinking
 >of it as a "visit" operation where the visitation method may in turn visit
 >the things it points to, if not already visited, descending through all the
 >classes much as it handles destructors which may delete objects they point
 >to.  In fact, since the visit mechanism would include some way of figuring out
 >whether an item had been visited or not, you could use this to DO your
 >destructors, and not have to handle circularities specially to avoid
 >an infinite recursion of delete's.

What you're really talking about is alowing member functions to be of
a certain `class'. ie Ctors, Dtors, assignment would be of this
hirerachical class. Other classes would include const and non-const.
IMHO this would be very useful as it would allow me to say something
to the effect "all non-const methods of this class should call the
modify() function".
 Ab.
--
+-------------------------------------+--------------------------+
| Disclaimer:                         | Obligatory silly quote:  |
| ``It was not me, it                 | ``Beam me up Scotty''    |
|   was the other four''              |     --- Captain Kirk     |
|     --- Rick (The Young Ones: Nasty)|                          |
+-------------------------------------+--------------------------+
| Ab Wilson <naw@planet.bt.co.uk>     | The Object Design Co Ltd |
+-------------------------------------+--------------------------+
GCS d--- p-- c+ l m- s+++/- !g w+++ t r- x++