🚀 go-pugleaf

In article <27CD159D.6581@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to peterson@choctaw.csc.ti.com (Bob Peterson):
>>In article <27C95D3A.1715@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>>>Presumably, a well-designed class hierarchy will use a virtual
>>>function to store objects ...
>>
>>Researchers and vendors have taken a number of implementation approaches
>>...  The details of the various implementations vary widely, but few depend
>>on virtual functions to supply type information.
>
>Is there any reason to avoid virtual functions for object storage?

The need to derive all "storable" types from a given base.  Among other
problems, you can't store an int or a char* that way.  If you are using a
single base class library, you can define store() and retrieve() in that
base.

But this is not flexible enough for most OODBs.  A more common approach is
to define keywords like "persistent" that can be applied to any object. 
This requires preprocessing outside the definition of C++.  

>I had not envisioned a virtual function to return type information,
>but rather a virtual function to actually _do_the_work_, so no one
>outside of that function need know the actual type of the object
>stored.

This works so long as you are prepared to write a new function for each
storable type.  This is not what I expect from an OODB.


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