On Fri, 29 Aug 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Fri, 29 Aug 2003, Leopold Toetsch wrote:
> >> Pluggable implies a dump() vtable method, doesn't it?
>
> > Nope. Pluggable implies freezethaw.c provides all the functionality to
> > freeze or thaw a PMC, with code in there to handle the right final
> > encoding or decoding of the data.
>
> I think, we need a general solution for freeze, dump and clone. As shown
> the latter is broken. That would be IMHO an iterator interface with a
> callback function taking and returning a void*.
Right, what I want is for the system freeze/thaw routines to have a
standard way to encode a variety of core types (ints, floats, strings),
lists, and hashes, as well as a way to handle self-referential, circular,
and shared data in the dumped PMC data. It's the only way to safely do
this, since we can't count on all the different PMC classes to handle
dumping arrays of arrays of references to the same end PMC properly. Which
we have to if we want this to work right.
> (The dump could be done from the frozen string too, but you might not
> always have all flags and such for just printing a PMC during tracing,
> so a special dump() vtable is more flexible - the PMCs should decide how
> they look like)
There's nothing to stop a PMC class from having a _pretty_print method
outside the vtable. (I'd rather keep pure debugging things out of the
vtables)
> > I thought we had a freeze and thaw entry in the vtables, but I see not.
> > The signatures (since I don't have source handy to check them in) should
> > be:
>
> > STRING *freeze()
>
> The freeze(), dump() and clone() would be vtables which are called by
> the iterator. So this functions hould have the same signature.
No iterator. When you call freeze on a PMC, that PMC is responsible for
any sort of iteration that may have to be done. (Though there is the issue
of blowing stack, which we'll have to address)
Dan
