chromatic wrote:
Regarding the function signatures in the vtable section: these should match
the calling conventions in PDD 07. I'm happy to patch them.
Go for it.
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.)
It means that you can simply call pobject_lives on an aggregate PMC
contained by your PMC, and expect the aggregate to take care of marking
its children. (If an aggregate doesn't mark its own children, that's a
bug in the aggregate.) You don't need to explicitly call 'VTABLE_mark'
on the aggregate or on its children.
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.
The whole series of 'set_bignum*' vtable entries are odd, and on my list
for possible deprecation.
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?
The text was using "NULL" (a specific technical value), in many places
where it should use "null" (a general description). Updated, and yes, in
that case PMCNULL was intended, so clarified.
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?
It doesn't really matter which one is marked, but the leading i_* is far
too cryptic. I would be happier with something like 'add_inplace_int'
or 'add_assign_int' than 'i_add_int'.
Regarding modulus and cmodulus, is it necessary to have both algorithms here?
They're both useful in certain contexts, but point taken that it'll be
an incredibly rare PMC that implements both. I'm fine with only
providing a vtable entry for 'modulus', and leaving it up to the PMC to
decide what implementation it uses. If there are no objections, enter it
in DEPRECATED.pod
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.
Excellent! Similarly removed from the PDD.
Allison
