Ilya:
> Perl needs a way to convert a Perl variable to/from a string. I
> thought you were talking about this. I see no reason why this
> should/may be platform specific.
Now that we're on the same wavelength... I agree. The specifics of
how I write out to a file are not an important part of what I was
playing with. A good standard way of writing objects to specified
files that happens at a low level would be useful. I might note that
there *IS* a public spec on this (or I presume it is now) in the
OpenStep spec. NeXT has had stringification for about 5 years or so
and it works quite nicely. I think that is a good place to go for
a starting point on "prior art".
> AFAIK, persistence is absolutely different question (though may/should
> be implemented using Stringification).
Yes, there are two parts, and I would say that the part I've been
playing around with is more at the mercy of the low level than vice versa.
So that said, I'll suggest a few requirements off the top of my head -
1) It should be possible to call a function that takes an entity as
an arg, and returns a list of everything that entity points to.
It is much easier to detect closed graphs at a level in which you
can do node marking to detect when you have already visited a
subgraph. The format isn't as important as the function.
2) A function that takes an entity as an arg an archives it in a current
file. There must be an ability to control recursive descent. A minimum
requirement probably is a switch between full recursion on the entity
or no following of pointers. Another option is to be able to hand
it a preprocessed list of objects. In this case, you have sets
of useful function calls that stringify their arguments and return
that string as the value.
Why?
In an object system, each object has to be treated individually because
it may need to override the behavior of the archive or unarchive. But
the existance of circular graphs makes this difficult. So with the above
one could do the following at the OBJECT level of the process:
A user method call to an archiver object with a pointer to the object
to be archived.
It makes a system call that "pulls the thread" on the object. It puts
this result in a hash. The Archiver then starts a recursive descent
of the entity and uses the hash as a means of marking whether a node
has been visited before. When an object is found, it is messaged
to ask what data it wishes to archive. The default behavior from the
inherited methods (from the root or Object class) is "everything".
The returned items are then stringified via system calls and appended
to the archive.
When the Archiver runs out of links to follow (this is a subset or
identity set to the list returned earlier) it makes a system call to
close this archive.
It should be possible for one file to contain multiple archive sessions.
I hope this makes it clear what I'm looking for. The actual format and
mechanism at the low level is less important than the ability to
break into the sequence of events at the required points.
There is a lot more behavior and finer control of the archive behavior,
but I can't see that as having an impact on the lower level design.
There are unanswered issues here as well. Since the OO environment I
came from most recently was ObjC, it was not interactive and thus
the idea of storing a fully persistant object was not a simple one.
But in Perl5 I see no reason why the actual methods and associated object
hierarchy could not also be archived. But there is great danger and
complexity here. With multiple inheritance you could end up archiving
nearly everything, and then there is the problem of what happens when
you try to unarchive the data into a new system that has a newer/older
version of the same object(s). I think these issues are best approached
cautiously.
Open for comment :-)