Index: docs/dev/pccmethods.pod =================================================================== --- docs/dev/pccmethods.pod (revision 43444) +++ docs/dev/pccmethods.pod (working copy) @@ -10,15 +10,14 @@ A C 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. This offers flexibility -not found in a PMC C or a vtable method using C calling conventions. +not found in a PMC C or a vtable function using C calling conventions. C is used to call a method using the Parrot Calling Conventions. It uses the standard find_method/invoke approach that the callmethodcc opcode -would. You can use C in any PMC method (including v-table methods), -even if they are not Cs. You can call methods that are not -implemented with C, too. +would. You can use C in any PMC method or vtable function, +even if they are not Cs. You can also use it to call methods that +are not implemented with C, too. - =head1 SYNTAX =head2 PCCMETHOD @@ -113,16 +112,16 @@ =head2 Performance -When a C or vtable method is called, C is used to map the +When a C or vtable function is called, C 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 to be any slower. It may well be faster. It's probably best to just not care. :-) It is clearly true that C is going to be more costly than an -invocation of a C method from another C method, if you do the call directly at -the C level. However, if you do that you are ignoring any method overrides if -you have been subclassed, and you wouldn't want to do that now, would you? +invocation of a C from another C, if you do the call directly +at the C level. However, if you do that you are ignoring any method overrides +if you have been subclassed, and you wouldn't want to do that now, would you? # vim: expandtab shiftwidth=2 tw=70: Index: docs/pdds/draft/pdd08_keys.pod =================================================================== --- docs/pdds/draft/pdd08_keys.pod (revision 43444) +++ docs/pdds/draft/pdd08_keys.pod (working copy) @@ -91,7 +91,7 @@ =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,11 +105,11 @@ =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 -add the C tag to the appropriate entry in F. They are -constructed by following B C argument with a second C +So what of these magical C<_keyed> vtable functions? They are generated when +you add the C tag to the appropriate entry in F. They +are constructed by following B C argument with a second C argument which acts as the key for that argument; the name of the second C argument is formed by adding C<_key> onto the end of the first C argument. @@ -123,9 +123,9 @@ $a = @b[$c] -use the same vtable method, reducing the multiplicity of methods. Secondly, a -three-argument C as suggested by the code above would be ambiguous - -the code above uses 3 PMCs in different ways. +use the same vtable function, reducing the multiplicity of these functions. +Secondly, a three-argument C as suggested by the code above would be +ambiguous - the code above uses 3 PMCs in different ways. Also, operations which take an aggregate key for one of their arguments should take aggregate keys for B of their arguments. This is to avoid the @@ -149,8 +149,8 @@ world situation are expected to be Cs anyway, this shouldn't be too much of a problem. -So, if you have a PMC in a C<_keyed> method which you don't want to index, -pass in C instead of a real key. Code implementing these methods should +So, if you have a PMC in a C<_keyed> function which you don't want to index, +pass in C instead of a real key. Code implementing these functions should understand C as meaning the entirety of C in some sense; this is trivial to understand if C is non-aggregate, and implementation-defined if C is aggregate. If you remember that a key PMC @@ -158,12 +158,12 @@ list, you'll reach a C which again means the entirety of whatever object you traversed to. -Similarly, non-C<_keyed> methods on aggregates are implementation defined; for -instance, a C on a C may be understood as setting +Similarly, non-C<_keyed> functions on aggregates are implementation defined; +for instance, a C on a C may be understood as setting C<@array.length>. -Historically, we first implemented keys as two separate keyed methods per -applicable method - C<..._index> and C<..._index_s> for integer and string +Historically, we first implemented keys as two separate keyed functions per +applicable function - C<..._index> and C<..._index_s> for integer and string indexing respectively. However, this didn't give us the flexibility and scalability that key structures give us. @@ -296,7 +296,7 @@ =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