#16 Persistant objects


My idea here is to have a method in all of the basic
classes that allows them to write themselves out to a
file and a complimentary method that allows them to
read themselves in. Complex objects desiring to be
persistant would need to implement the same methods,
using the basic class methods as building blocks.

To my mind, the tricky part is how to roll an object
back in, if one doesn't know ahead of time just what
kind of object it is. This would seem to require an
object check-sum, and a lookup table. And it would
need to be legal to throw an exception if there was
an attempt to roll in an object of an undefined
(unknown) type. (And the file would need to be able
to be rolled forward so that the unknown object could
just be skipped, or just read in as a blob, and let
the user deal with it.)

My idea would be to implement the storage of the
objects as a B+Tree, but the actual key definition
would need to be left to the user, because the user
would need to specify the keys by which to retrieve
it. It would be nice to have some supporting
routines that, perhaps, made it easy for the user to
do reference counting and garbage collection on the
tree. System implemented garbage collection would be
impossible, as there might well be external links to
the objects. In fact, there would need to be. And I
don't think that mark and sweep could be made to work
even by the user, though perhaps in simple cases...


  • J. Scott Edwards

    Logged In: YES

    Interesting ideas. Similar to Feature Request #408199 -
    Storable Classes.

  • J. Scott Edwards

    • labels: --> New Compiler Feature
    • milestone: --> Evaluation

Log in to post a comment.