Regarding the function signatures in the vtable section: these should match
the calling conventions in PDD 07. I'm happy to patch them.
Regarding the mark vtable entry:
This method does not have
to call the "mark" method on any PMCs it marks--the DOD system
takes care of that. (So no need to recurse into aggregate PMCs or
anything of the sort).
I take this to mean that calling pobject_lives(INTERP, some_pobj) is
sufficient, and will call the mark() vtable entry on some_pobj if it turns
out to be a PMC (which I know it does). I don't understand what "no need to
recurse into aggregate PMCs" means though.
Within an array-like PMC's mark(), doesn't it have to mark each contained PMC
appropriately? Or does this parenthetical note mean something else?
(I'm aware of the special PObj flag which obviates this, but I don't trust it
or like it.)
Regarding the set_bignum_int vtable entry: this is the only vtable entry so
far that morphs in place (besides morph, of course). This seems odd.
Regarding aggregate PMC vtable entries:
The PMC* parameter is NULL if there is no
key for that PMC; this means that that argument is unkeyed.
The PMCNULL/NULL isomorphism assumption bothers me. Can this be PMCNULL
instead?
Regarding the i_* versions of the math and bitwise vtable entries, it seems
like the naming scheme is backwards. All other vtable entries operate on the
PMC in place. The vtable entries that produce a destination PMC are the
oddities here; perhaps they are the ones that need different names?
Regarding modulus and cmodulus, is it necessary to have both algorithms here?
Regarding the invoke vtable entry, there's no documentation for the next void
pointer.
Regarding the Boolean PMC, the Python true and false are long gone.
-- c
