Ticket #487: replace-vtable-method-stage2.patch
| File replace-vtable-method-stage2.patch, 5.8 KB (added by Aninhumer, 12 years ago) |
|---|
-
docs/dev/pccmethods.pod
10 10 A C<PCCMETHOD> is a PMC method that follows Parrot Calling Conventions 11 11 (a.k.a. PCC). This allows PIR code to call PMC methods using slurpy, named, 12 12 and other types of arguments as specified in F<PDD03>. This offers flexibility 13 not found in a PMC C<METHOD> or a vtable methodusing C calling conventions.13 not found in a PMC C<METHOD> or a vtable function using C calling conventions. 14 14 15 15 C<PCCINVOKE> is used to call a method using the Parrot Calling Conventions. 16 16 It uses the standard find_method/invoke approach that the callmethodcc opcode 17 would. You can use C<PCCINVOKE> in any PMC method (including v-table methods),18 even if they are not C<PCCMETHOD>s. You can call methods that are not19 implemented with C<PCCMETHOD>, too.17 would. You can use C<PCCINVOKE> in any PMC method or vtable function, 18 even if they are not C<PCCMETHOD>s. You can also use it to call methods that 19 are not implemented with C<PCCMETHOD>, too. 20 20 21 22 21 =head1 SYNTAX 23 22 24 23 =head2 PCCMETHOD … … 113 112 114 113 =head2 Performance 115 114 116 When a C<METHOD> or vtable methodis called, C<NCI> is used to map the115 When a C<METHOD> or vtable function is called, C<NCI> is used to map the 117 116 arguments held in the current Parrot_Context onto the C calling conventions. 118 117 That is, you still end up involving the Parrot Calling Conventions anyway, 119 118 so there is no reason to expect a C<PCCMETHOD> to be any slower. It may well 120 119 be faster. It's probably best to just not care. :-) 121 120 122 121 It is clearly true that C<PCCINVOKE> is going to be more costly than an 123 invocation of a C method from another C method, if you do the call directly at124 the C level. However, if you do that you are ignoring any method overrides if 125 you have been subclassed, and you wouldn't want to do that now, would you?122 invocation of a C<METHOD> from another C<METHOD>, if you do the call directly 123 at the C level. However, if you do that you are ignoring any method overrides 124 if you have been subclassed, and you wouldn't want to do that now, would you? 126 125 127 126 128 127 # vim: expandtab shiftwidth=2 tw=70: -
docs/pdds/draft/pdd08_keys.pod
91 91 =head3 Aggregate and non-aggregate PMCs 92 92 93 93 We've already said that what separates the aggregate PMCs from the 94 non-aggregates is their implementation of the C<_keyed> vtable methods. So it94 non-aggregates is their implementation of the C<_keyed> vtable functions. So it 95 95 is Hereby Decreed that the default vtable which everyone inherits from defines 96 96 the C<_keyed> forms to throw an exception. 97 97 … … 105 105 106 106 =back 107 107 108 =head3 C<_keyed> vtable methods108 =head3 C<_keyed> vtable functions 109 109 110 So what of these magical C<_keyed> vtable methods? They are generated when you111 add the C<keyed> tag to the appropriate entry in F<src/vtable.tbl>. They are 112 constructed by following B<every> C<PMC> argument with a second C<PMC>110 So what of these magical C<_keyed> vtable functions? They are generated when 111 you add the C<keyed> tag to the appropriate entry in F<src/vtable.tbl>. They 112 are constructed by following B<every> C<PMC> argument with a second C<PMC> 113 113 argument which acts as the key for that argument; the name of the second 114 114 C<PMC> argument is formed by adding C<_key> onto the end of the first C<PMC> 115 115 argument. … … 123 123 124 124 $a = @b[$c] 125 125 126 use the same vtable method, reducing the multiplicity of methods. Secondly, a127 three-argument C<assign> as suggested by the code above would be ambiguous - 128 the code above uses 3 PMCs in different ways.126 use the same vtable function, reducing the multiplicity of these functions. 127 Secondly, a three-argument C<assign> as suggested by the code above would be 128 ambiguous - the code above uses 3 PMCs in different ways. 129 129 130 130 Also, operations which take an aggregate key for one of their arguments should 131 131 take aggregate keys for B<all> of their arguments. This is to avoid the … … 149 149 world situation are expected to be C<PMC>s anyway, this shouldn't be too much 150 150 of a problem. 151 151 152 So, if you have a PMC in a C<_keyed> methodwhich you don't want to index,153 pass in C<NULL> instead of a real key. Code implementing these methods should152 So, if you have a PMC in a C<_keyed> function which you don't want to index, 153 pass in C<NULL> instead of a real key. Code implementing these functions should 154 154 understand C<PMC* foo, PMC* NULL> as meaning the entirety of C<foo> in some 155 155 sense; this is trivial to understand if C<foo> is non-aggregate, and 156 156 implementation-defined if C<foo> is aggregate. If you remember that a key PMC … … 158 158 list, you'll reach a C<NULL> which again means the entirety of whatever object 159 159 you traversed to. 160 160 161 Similarly, non-C<_keyed> methods on aggregates are implementation defined; for162 instance, a C<set_integer> on a C<PerlArray> may be understood as setting161 Similarly, non-C<_keyed> functions on aggregates are implementation defined; 162 for instance, a C<set_integer> on a C<PerlArray> may be understood as setting 163 163 C<@array.length>. 164 164 165 Historically, we first implemented keys as two separate keyed methods per166 applicable method- C<..._index> and C<..._index_s> for integer and string165 Historically, we first implemented keys as two separate keyed functions per 166 applicable function - C<..._index> and C<..._index_s> for integer and string 167 167 indexing respectively. However, this didn't give us the flexibility and 168 168 scalability that key structures give us. 169 169 … … 296 296 =item Fri Mar 8 18:47:34 GMT 2002 : Version 1.1 297 297 298 298 updated to reflect Dan's comments that non-aggregates also support C<_keyed> 299 variant vtable methods.299 variant vtable functions. 300 300 301 301 =back 302 302
