> > Having an OODB would be great, but I wouldn't want it to be using
> > persistent objects though as that means that only the published properties
> > get saved. What if there is a private attribute of a class that I want
> > saved? An internal state variable for instance, I don't want to have to
> > make it published just to save it. I would want to keep it private in
> > keeping with normal OO methodology.
> Where is the rule that says that OODBs can't have persistent
> private properties??
> Have I missed something?
Possibly... Delphi is compiled rather than interpreted and as such there is no
overseer with a 'definition' of each class... All the program has to go by (during
the storage and restore phase) is RTTI and it was my understanding that the
only information stored in the executable about properties and storage were for
published properties.
The automated storage into a database (including constraints etc) would need
to know which properties to be written to the DB as a valid representation of the
object. These properties may be private, protected, public or published.
It's possible a DefineProperties type mechanism could be created and all OODB
work done through a base class designed for automated storage enabling the
functionality without language syntax extensions - however this doesn't save the
developer as much work as extensions could achieve.
NB Has anyone used the ORACLE8 nexted tables and Object types? How are
nested tables retrieved in Queries accessed in Delphi (point me to documentation?)...
--
Aaron Scott-Boddendijk
Jump Productions
(07) 838-3371 Voice
(07) 838-3372 Fax
---------------------------------------------------------------------------
New Zealand Delphi Users group - Offtopic List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
