Ticket #487: replace-vtable-method-stage1.patch

docs/book/draft/ch07_dynpmcs.pod

@@ -195 +195 @@
 =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 */

docs/book/draft/chXX_hlls.pod

@@ -211 +211 @@
 
 =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.

docs/pmc/documentation.pod

@@ -36 +36 @@
  F<docs/pdds/pdd21_namespaces.pod>.
 
  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<DESCRIPTION> section is further broken down as follows:
 

src/pmc/exporter.pmc

@@ -49 +49 @@
 F<docs/pdds/pdd21_namespaces.pod>.
 
 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
 

docs/pdds/draft/pdd06_pasm.pod

@@ -172 +172 @@
 where register_type is 0x100, 0x200, 0x400, or 0x800 for PMC, string, integer,
 or number respectively. So N19 would be 0x413.
 
-B<Note>: Instructions tagged with a * will call a vtable method to handle the
-instruction if used on PMC registers.
+B<Note>: 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 +244 @@
 
     $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
 

docs/pdds/draft/pdd10_embedding.pod

@@ -74 +74 @@
 
 =back
 
-=item * probably includes vtable methods on PMCs
+=item * probably includes vtable functions on PMCs
 
 =back
 

docs/pdds/pdd09_gc.pod

@@ -421 +421 @@
 =item C<void (*finalize_gc_system) (Interp *)>
 
 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<void (*init_pool) (Interp *, Fixed_Size_Pool *)>
 
@@ -563 +563 @@
 The C<mark> vtable slot will be called during the GC mark phase. The mark
 function must call C<Parrot_gc_mark_PObj_alive> 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<src/gc/api.c:mark_special>.
+custom mark VTABLE function called from C<src/gc/api.c:mark_special>.
 
 =item PObj_external_FLAG
 

docs/dev/infant.pod

@@ -142 +142 @@
  + 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
 

docs/pdds/pdd17_pmc.pod

@@ -1636 +1636 @@
 
 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 +1649 @@
 A weak register reference can only be created by the C<register_ref> 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