Deprecate freeze, thaw, and thawfinish VTABLEs

[whiteknight]

I would like to deprecate the freeze, thaw, and thawfinish vtables as they currently exist. freeze and thaw can both be implemented with the existing "visit" vtable. In many cases, freeze and thaw already redirect to visit. For consistency, I would like to rename thawfinish to "visitfinish". We do not need to modify thawfinish any further.

[cotto]

The serialization code is baroque and hard to wrap one's head around, but it won't be especially helpful to our users to deprecate the current system before a feasible replacement is in place. Could you spell out the changes you're suggesting and how existing code will be effected?

[whiteknight]

not counting the generated code in src/extend_vtable.c, the vtables freeze, thaw, thawfinish, and visit are all called exactly once: in src/packfile/object_serialization.c:Parrot_visit_loop_visit. Here's the relevant snippet, with some details removed:

const INTVAL action = VTABLE_get_integer(interp, info);
...
if (action == VISIT_FREEZE_NORMAL)
    VTABLE_freeze(interp, current, info);
else
    VTABLE_thaw(interp, current, info);

VTABLE_visit(interp, current, info);

What I am suggesting we do is to move the logic from VTABLE_thaw and VTABLE_freeze into VTABLE_visit. We have all the information in the info PMC that we need to select the appropriate behaviors. This is also a process that we could complete gradually: We can move logic out of VTABLE_freeze and VTABLE_thaw gradually without breaking anything, and when we're done we eliminate two vtables.

[jkeenan]

cotto, whiteknight:

Can we get an update on the status of this ticket?

Thank you very much.

kid51