Eliminate 'vtable method'. It's a vtable, or a vtable function.

This resolves TT #487



git-svn-id: https://svn.parrot.org/parrot/trunk@45297 d31e2699-5ff4-0310-a27c-f18f2fbe73fe

compilers/imcc/pbc.c

@@ -1395,7 +1395,7 @@ add_const_pmc_sub(PARROT_INTERP, ARGMOD(SymReg *r), size_t offs, size_t end)
         STRING *vtable_name;
         INTVAL  vtable_index;
 
-        /* Work out the name of the vtable method. */
+        /* Work out the name of the vtable function. */
         if (unit->vtable_name) {
             vtable_name = Parrot_str_new(interp, unit->vtable_name + 1,
                     strlen(unit->vtable_name) - 2);
@@ -1404,7 +1404,7 @@ add_const_pmc_sub(PARROT_INTERP, ARGMOD(SymReg *r), size_t offs, size_t end)
         else
             vtable_name = sub->name;
 
-        /* Check this is a valid vtable method to override. */
+        /* Check this is a valid vtable function to override. */
         vtable_index = Parrot_get_vtable_index(interp, vtable_name);
 
         if (vtable_index == -1) {

compilers/pct/src/POST/Node.pir

@@ -82,7 +82,7 @@ as the result of the current node.
 .end
 
 
-=item get_string()   # vtable method
+=item get_string()
 
 Returns the result of the current node as a string.
 

compilers/pirc/src/pircompunit.c

@@ -274,9 +274,9 @@ add_self_parameter(ARGIN(lexer_state * const lexer))
 =item C<void set_sub_vtable(lexer_state * const lexer, char const * vtablename)>
 
 Set the :vtable() flag argument to the current subroutine. If C<vtablename>
-is NULL, the name of the current sub is taken to be the vtable method name.
-If the vtable method name (either specified or the current sub's name) is
-in fact not a vtable method, an error message is emitted.
+is NULL, the name of the current sub is taken to be the vtable name.
+If the vtable name (either specified or the current sub's name) is
+not a valid vtable, an error message is emitted.
 
 =cut
 
@@ -290,15 +290,15 @@ set_sub_vtable(ARGIN(lexer_state * const lexer),
     if (vtablename == NULL)  /* the sub's name I<is> the vtablename */
         vtablename = CURRENT_SUB(lexer)->info.subname;
 
-    /* get the index number of this vtable method */
+    /* get the index number of this vtable */
     vtable_index = Parrot_get_vtable_index(lexer->interp,
                                            Parrot_str_new(lexer->interp, vtablename,
                                                                strlen(vtablename)));
 
-    /* now check whether the method name actually a vtable method */
+    /* now check whether the method name actually a vtable */
     if (vtable_index == -1)
         yypirerror(lexer->yyscanner, lexer,
-                   "'%s' is not a vtable method but was used with :vtable flag", vtablename);
+                   "'%s' is not a vtable but was used with :vtable flag", vtablename);
 
     else {
         /* test for duplicate :vtable on a sub */

docs/book/draft/ch07_dynpmcs.pod

@@ -195,7 +195,7 @@ when building Parrot.
 =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,9 +211,9 @@ at the data level? There are two ways:
 
 =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/dev/infant.pod

@@ -142,15 +142,15 @@ opcodes, so that there is no chance of unanchored temporaries.
  + 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/dev/pccmethods.pod

@@ -10,7 +10,7 @@ docs/dev/pccmethods.pod - Parrot Calling Conventions in C
 A C<PCCMETHOD> is a PMC method that follows Parrot Calling Conventions
 (a.k.a. PCC). This allows PIR code to call PMC methods using slurpy, named,
 and other types of arguments as specified in F<PDD03>. This offers flexibility
-not found in a PMC C<METHOD> or a vtable method using C calling conventions.
+not found in a PMC C<METHOD> or a vtable function using C calling conventions.
 
 C<PCCINVOKE> is used to call a method using the Parrot Calling Conventions.
 It uses the standard find_method/invoke approach that the callmethodcc opcode
@@ -113,7 +113,7 @@ not next to the type.
 
 =head2 Performance
 
-When a C<METHOD> or vtable method is called, C<NCI> is used to map the
+When a C<METHOD> or vtable function is called, C<NCI> is used to map the
 arguments held in the current Parrot_Context onto the C calling conventions.
 That is, you still end up involving the Parrot Calling Conventions anyway,
 so there is no reason to expect a C<PCCMETHOD> to be any slower. It may well

docs/dev/pmc_freeze.pod

@@ -79,7 +79,7 @@ The basic scheme of operation looks like this:
 =head2 The visit_info structure
 
 This structure holds all necessary information and function pointers specific
-to the desired functionality. It gets passed on to all vtable methods and
+to the desired functionality. It gets passed on to all vtable functions and
 callback functions.
 
 =head2 Working loop
@@ -99,7 +99,7 @@ thread-safe.
 This is done by a callback function inside the B<visit_info> structure called
 B<visit_pmc_now>. It gets called initially to put the first item on the list
 and is called thereafter from all PMCs for contained PMCs inside the B<visit>
-vtable method.
+vtable function.
 
 
 =head2 The visit() vtable
@@ -140,19 +140,19 @@ amount of time.
 
 So after all we finally arrived at the point to actually perform the desired
 functionality. First the PMC-specific part is done inside F<pmc_freeze.c> then
-the specific vtable method B<freeze>, B<thaw>, whatever, is called, again via a
-function pointer called B<visit_action>.
+the specific vtable function B<freeze>, B<thaw>, whatever, is called, again
+via a function pointer called B<visit_action>.
 
 =head1 Freeze and thaw
 
 As stated PMCs are currently processed inside the core, PMC-specific parts are
-done by calling the PMCs vtable method. This parts could of course be moved to
+done by calling the PMCs vtable function. This parts could of course be moved to
 F<default.pmc> too, so that it's simpler to override the functionality.
 
 =head2 Serializer interface
 
 During initialization the B<visit_info>s B<image_io> data pointer is filled
-with an object having B<vtable> methods that remarkably look like a PMCs
+with an object having B<vtable> functions that remarkably look like a PMCs
 vtable. So B<io-E<gt>vtable-E<gt>push_integer> spits out an INTVAL to the
 frozen B<image>, while B<shift_integer> gets an INTVAL from the frozen stream.
 

docs/dev/pmc_obj_design_meeting_notes.pod

@@ -60,7 +60,7 @@ worthy of the name SELF, it is DYNSELF. DYNSELF does dispatching, while SELF
 statically calls the method in the current class.
 
 B<Recommendation>: Throughout the source, rename SELF to STATIC_SELF, and
-rename DYNSELF to SELF. Additionally, direct access to VTABLE methods should
+rename DYNSELF to SELF. Additionally, direct access to VTABLE functions should
 be reviewed, and SELF should be used where possible to increase clarity and
 maintainability (this is a good CAGE task.) Also, this should become a coding
 standard for PMCs.

docs/pdds/draft/pdd06_pasm.pod

@@ -172,7 +172,7 @@ of the form:
 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
+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
@@ -244,7 +244,7 @@ does a value assignment, as:
 
     $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/pdd08_keys.pod

@@ -91,7 +91,7 @@ manipulate keys, can be found in F<include/parrot/key.h>
 =head3 Aggregate and non-aggregate PMCs
 
 We've already said that what separates the aggregate PMCs from the
-non-aggregates is their implementation of the C<_keyed> vtable methods. So it
+non-aggregates is their implementation of the C<_keyed> vtable functions. So it
 is Hereby Decreed that the default vtable which everyone inherits from defines
 the C<_keyed> forms to throw an exception.
 
@@ -105,9 +105,9 @@ screw-up, since code which indexes a non-aggregate shouldn't be generated.
 
 =back
 
-=head3 C<_keyed> vtable methods
+=head3 C<_keyed> vtable functions
 
-So what of these magical C<_keyed> vtable methods? They are generated when you
+So what of these magical C<_keyed> vtable functions? They are generated when you
 add the C<keyed> tag to the appropriate entry in F<src/vtable.tbl>. They are
 constructed by following B<every> C<PMC> argument with a second C<PMC>
 argument which acts as the key for that argument; the name of the second
@@ -123,7 +123,7 @@ and
 
     $a = @b[$c]
 
-use the same vtable method, reducing the multiplicity of methods.  Secondly, a
+use the same vtable function, reducing the multiplicity of methods.  Secondly, a
 three-argument C<assign> as suggested by the code above would be ambiguous -
 the code above uses 3 PMCs in different ways.
 
@@ -296,7 +296,7 @@ list. - steve@fink.com
 =item Fri Mar  8 18:47:34 GMT 2002 : Version 1.1
 
 updated to reflect Dan's comments that non-aggregates also support C<_keyed>
-variant vtable methods.
+variant vtable functions.
 
 =back
 

docs/pdds/draft/pdd10_embedding.pod

@@ -74,7 +74,7 @@ Perl 5 problem
 
 =back
 
-=item * probably includes vtable methods on PMCs
+=item * probably includes vtable functions on PMCs
 
 =back
 

docs/pdds/pdd09_gc.pod

@@ -421,7 +421,7 @@ proper operation.
 =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
+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,7 +563,7 @@ within C<src/gc/api.c:Parrot_gc_free_pmc>.
 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/pdds/pdd17_pmc.pod

@@ -1656,7 +1656,7 @@ C<ResizablePMCArray>, but that's likely to change.
 =head4 Array types
 
 Note that for the following types you can set the size of the array by using
-the VTABLE_set_integer_native() method. Assigning an integer to the array as a
+the VTABLE_set_integer_native() function. Assigning an integer to the array as a
 whole sets the array to that size.
 
 Size-changing operations (such as push, pop, shift, unshift, and splice)

docs/pmc/documentation.pod

@@ -36,7 +36,8 @@ in the C<pmclass> declaration.
  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, not
+ vtable functions.
 
 The B<DESCRIPTION> section is further broken down as follows:
 

docs/pmc2c.pod

@@ -144,7 +144,7 @@ types are generally only used by low-level internal PMCs.
 
 =item 4.
 
-A list of vtable method implementations
+A list of vtable function implementations
 
 =item 5.
 
@@ -154,7 +154,7 @@ The final close C<}>
 
 =head2 Method Body Substitutions
 
-The vtable method bodies can use the following substitutions:
+The vtable function bodies can use the following substitutions:
 
 =over 4
 
@@ -168,19 +168,19 @@ Converted to the interpreter object.
 
 =item C<OtherClass.SELF.method(a,b,c)>
 
-Calls the static vtable method 'method' in C<OtherClass>.
+Calls the static vtable or method 'method' in C<OtherClass>.
 
 =item C<SELF.method(a,b,c)>
 
-Calls the vtable method 'method' using the dynamic type of C<SELF>.
+Calls the vtable or method 'method' using the dynamic type of C<SELF>.
 
 =item C<SELF(a,b,c)>
 
 Same as above, but calls the current method.
 
 =item C<STATICSELF.method(a,b,c)>
 
-Calls the vtable method 'method' using the static type of C<SELF> (in
+Calls the vtable or method 'method' using the static type of C<SELF> (in
 other words, calls another method defined in the same file).
 
 =item C<OtherClass.SUPER(a,b,c)>

examples/tutorial/56_defined.pir

@@ -26,7 +26,7 @@ been defined may throw an exception or cause a bigger problem.
 =pod
 
 Most PMC's, but not all, should return true for C<defined>.  It all
-depends on how the PMC implements its vtable method for C<defined>.
+depends on how the PMC implements its vtable function for C<defined>.
 For example the C<Undef> PMC always returns false (0) for C<defined>.
 
 =cut

lib/Parrot/Pmc2c/MethodEmitter.pm

@@ -163,7 +163,7 @@ sub rewrite_nci_method {
 =item C<rewrite_vtable_method($self, $pmc, $super, $super_table)>
 
 Rewrites the method body performing the various macro substitutions for
-vtable method bodies (see F<tools/build/pmc2c.pl>).
+vtable function bodies (see F<tools/build/pmc2c.pl>).
 
 =cut
 
@@ -180,7 +180,7 @@ sub rewrite_vtable_method {
     # Some MMD variants don't have a super mapping.
     if ($super) {
         my $supertype = "enum_class_$super";
-        die "$pmcname defines unknown vtable method '$name'\n" unless defined $super_table->{$name};
+        die "$pmcname defines unknown vtable function '$name'\n" unless defined $super_table->{$name};
         my $supermethod = "Parrot_" . $super_table->{$name} . "_$name";
 
         # Rewrite OtherClass.SUPER(args...)

lib/Parrot/Pmc2c/Object.pm

@@ -37,8 +37,8 @@ the number of lines, C<$out_name> is the name of the output file we are
 generating.
 
 Overrides the default implementation to direct all unknown methods to
-first check if there is an implementation of the vtable method in the
-vtable methods hash of this class of any others, and delegates up to
+first check if there is an implementation of the vtable function in the
+vtable function hash of this class of any others, and delegates up to
 any PMCs in the MRO.
 
 =back

lib/Parrot/Pmc2c/PMC.pm

@@ -132,7 +132,7 @@ Determines if a given PMC type is dynamically loaded or not.
 
 =item C<implements_vtable($method)>
 
-True if pmc generates code for vtable method C<$method>.
+True if pmc generates code for vtable C<$method>.
 
 =cut
 
@@ -321,7 +321,7 @@ sub method_attrs {
 
 =item C<vtable_method_does_write($method)>
 
-Returns true if the vtable method C<$method> writes our value.
+Returns true if the vtable C<$method> writes our value.
 
 =back
 

lib/Parrot/Pmc2c/PMC/Null.pm

@@ -29,7 +29,7 @@ The C<Null> PMC throws an execption for all methods.
 sub pre_method_gen {
     my ($self) = @_;
 
-    # vtable methods
+    # vtables
     foreach my $method ( @{ $self->vtable->methods } ) {
         my $vt_method_name = $method->name;
         next unless $self->normal_unimplemented_vtable($vt_method_name);