Index: docs/book/draft/ch07_dynpmcs.pod =================================================================== --- docs/book/draft/ch07_dynpmcs.pod (revision 43444) +++ docs/book/draft/ch07_dynpmcs.pod (working copy) @@ -195,7 +195,7 @@ =head3 VTABLE Functions Parameters VTABLE functions are defined just like ordinary C functions, almost. Here's -a normal definition for a VTABLE method: +a normal definition for a VTABLE function: VTABLE VTABLENAME (PARAMETERS) { /* ordinary C here, almost */ Index: docs/book/draft/chXX_hlls.pod =================================================================== --- docs/book/draft/chXX_hlls.pod (revision 43444) +++ docs/book/draft/chXX_hlls.pod (working copy) @@ -211,9 +211,9 @@ =over 4 -=item * VTable methods +=item * VTable functions -VTable methods are the standard interface for PMC data types, and all PMCs +VTable functions are the standard interface for PMC data types, and all PMCs have them. If the PMCs were written properly to satisfy this interface all the necessary information from those PMCs. Operate on the PMCs at the VTable level, and we can safely ignore the implementation details of them. Index: docs/pmc/documentation.pod =================================================================== --- docs/pmc/documentation.pod (revision 43444) +++ docs/pmc/documentation.pod (working copy) @@ -36,7 +36,7 @@ F. Exporter is not derived from any other PMC, and does not provide any - standard interface--its interface consists solely of non-vtable methods. + standard interface--its interface consists solely of methods. The B section is further broken down as follows: Index: src/pmc/exporter.pmc =================================================================== --- src/pmc/exporter.pmc (revision 43444) +++ src/pmc/exporter.pmc (working copy) @@ -49,7 +49,7 @@ F. Exporter is not derived from any other PMC, and does not provide any -vtable interface--its interface consists solely of non-vtable methods. +vtable interface--its interface consists solely of methods. =head2 Structure Index: docs/pdds/draft/pdd06_pasm.pod =================================================================== --- docs/pdds/draft/pdd06_pasm.pod (revision 43444) +++ docs/pdds/draft/pdd06_pasm.pod (working copy) @@ -172,8 +172,8 @@ where register_type is 0x100, 0x200, 0x400, or 0x800 for PMC, string, integer, or number respectively. So N19 would be 0x413. -B: Instructions tagged with a * will call a vtable method to handle the -instruction if used on PMC registers. +B: Instructions tagged with a * will call a vtable function to handle +the instruction if used on PMC registers. In all cases, the letters x, y, and z refer to register numbers. The letter t refers to a generic register (P, S, I, or N). A lowercase p, s, i, or n means @@ -244,7 +244,7 @@ $foo = $bar; -X's assign vtable method is invoked and it does whatever is appropriate. +X's assign vtable function is invoked and it does whatever is appropriate. =item clone Px, Py Index: docs/pdds/draft/pdd10_embedding.pod =================================================================== --- docs/pdds/draft/pdd10_embedding.pod (revision 43444) +++ docs/pdds/draft/pdd10_embedding.pod (working copy) @@ -74,7 +74,7 @@ =back -=item * probably includes vtable methods on PMCs +=item * probably includes vtable functions on PMCs =back Index: docs/pdds/pdd09_gc.pod =================================================================== --- docs/pdds/pdd09_gc.pod (revision 43444) +++ docs/pdds/pdd09_gc.pod (working copy) @@ -421,8 +421,8 @@ =item C Called during interpreter destruction. Free used resources and memory pools. -All PMCs must be swept, and PMCs with custom destroy VTABLE methods must have -those called. +All PMCs must be swept, and PMCs with custom destroy VTABLE functions must +have those called. =item C @@ -563,7 +563,7 @@ The C vtable slot will be called during the GC mark phase. The mark function must call C for all non-NULL objects (Buffers and PMCs) that PMC refers to. This flag is typically tested and the -custom mark VTABLE method called from C. +custom mark VTABLE function called from C. =item PObj_external_FLAG Index: docs/dev/infant.pod =================================================================== --- docs/dev/infant.pod (revision 43444) +++ docs/dev/infant.pod (working copy) @@ -142,15 +142,15 @@ + Fast mark phase (GC already manipulates the flags) - Generation count must be maintained - Disallows recursive opcode calls (necessary for eg implementing - vtable methods in pasm) + vtable functions in pasm) - Can temporarily use more memory (dead objects accumulate during the current generation) In order to allow recursive opcode calls, we could increment the generation count in more places and make sure nothing is left unanchored at those points, but that would gradually remove all advantages of this scheme and make it more -difficult to call existing vtable methods (since you never know when they might -start running pasm code.) +difficult to call existing vtable functions (since you never know when they +might start running pasm code.) =head2 Variant 5: generation stack Index: docs/pdds/pdd17_pmc.pod =================================================================== --- docs/pdds/pdd17_pmc.pod (revision 43444) +++ docs/pdds/pdd17_pmc.pod (working copy) @@ -1636,7 +1636,7 @@ Note that assigning to the reference PMC will be equivalent to a keyed set on the referenced aggregate PMC - that is, it modifies the element rather than -doing a v-table call on the element itself. It is important to be aware of +doing a vtable call on the element itself. It is important to be aware of this when assigning a PMC through this reference; it is not the same behaviour as the Ref PMC. @@ -1649,7 +1649,7 @@ A weak register reference can only be created by the C opcode. Any assignment to the register will behave like a set instruction. That is, when assigning a PMC using a WeakRegisterRef PMC, the register will be updated -to reference that PMC rather than calling the assign v-table call on the PMC +to reference that PMC rather than calling the assign vtable call on the PMC in that register. This is not the same behaviour as the Ref PMC. =item Exception