Dan Sugalski <[EMAIL PROTECTED]> wrote: > 5) The vtable API
[ ... ] > thawfinish() This is very probably necessary to perform some final state adjustemnt, when all the contained PMCs are done but not as a general "to be called on each". E.g. a plain scalar PMC doesn't need it. I'd rather have such functionality on demand i.e. a PMC on freezing sets a flag: "I need post-processing". > 6) The freeze/thaw library needs to consist of the following calls (some > of which we already have) [ ... ] > startlist(name) > endlist(name) > startpairs(name) > endpairs(name) Do you have some more info about above functions and what they are intended to perform? > addpmctolist(pmc *) Doesn't fit into the scheme. The latter tells the engine, to put a PMC on the todo_list. That ought to be part of the context (info) structure. All the other library functions are serializer-specific. > The freezepmc routine here, it should be noted, acts as a mark routine of > sorts, which is why we don't need one on the PMC itself for this. That doesn't play with other usage of vtable->visit like destruction ordering. When going that way, we are loosing the generalization that currently is in the scheme. (At least if you are using the term "mark" here as what vtable->visit() now is). > Leo's idea of passing in a struct as part of the freeze is a good one, as > one of the things hanging off it can be a vtable with all these calls in > it, so we can have multiple freeze methods active at once. (Arguments as > to why that's a good thing are separate and I don't want to go there :) Actually, I'm (longterm) thinking of making a PMC out of PackFile_<xxx> and what's now called IMAGE_IO. The generalization could be finally: Writing a .pbc file image is freezing/writing such a PackFile PMC. Or adding an item to a packfile is appending a frozen image. Having all this functionality inside one or more PMCs, makes it easy to change these formats - even to xml (brrr). > Dan leo
