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

File replace-vtable-method-stage2.patch, 5.8 KB (added by Aninhumer, 5 years ago)

Less certain about these fixes

  • docs/dev/pccmethods.pod

     
    1010A C<PCCMETHOD> is a PMC method that follows Parrot Calling Conventions 
    1111(a.k.a. PCC). This allows PIR code to call PMC methods using slurpy, named, 
    1212and other types of arguments as specified in F<PDD03>. This offers flexibility 
    13 not found in a PMC C<METHOD> or a vtable method using C calling conventions. 
     13not found in a PMC C<METHOD> or a vtable function using C calling conventions. 
    1414 
    1515C<PCCINVOKE> is used to call a method using the Parrot Calling Conventions. 
    1616It 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 not 
    19 implemented with C<PCCMETHOD>, too. 
     17would. You can use C<PCCINVOKE> in any PMC method or vtable function, 
     18even if they are not C<PCCMETHOD>s. You can also use it to call methods that 
     19are not implemented with C<PCCMETHOD>, too. 
    2020 
    21  
    2221=head1 SYNTAX 
    2322 
    2423=head2 PCCMETHOD 
     
    113112 
    114113=head2 Performance 
    115114 
    116 When a C<METHOD> or vtable method is called, C<NCI> is used to map the 
     115When a C<METHOD> or vtable function is called, C<NCI> is used to map the 
    117116arguments held in the current Parrot_Context onto the C calling conventions. 
    118117That is, you still end up involving the Parrot Calling Conventions anyway, 
    119118so there is no reason to expect a C<PCCMETHOD> to be any slower. It may well 
    120119be faster. It's probably best to just not care. :-) 
    121120 
    122121It 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 at 
    124 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? 
     122invocation of a C<METHOD> from another C<METHOD>, if you do the call directly 
     123at the C level. However, if you do that you are ignoring any method overrides 
     124if you have been subclassed, and you wouldn't want to do that now, would you? 
    126125 
    127126 
    128127# vim: expandtab shiftwidth=2 tw=70: 
  • docs/pdds/draft/pdd08_keys.pod

     
    9191=head3 Aggregate and non-aggregate PMCs 
    9292 
    9393We've already said that what separates the aggregate PMCs from the 
    94 non-aggregates is their implementation of the C<_keyed> vtable methods. So it 
     94non-aggregates is their implementation of the C<_keyed> vtable functions. So it 
    9595is Hereby Decreed that the default vtable which everyone inherits from defines 
    9696the C<_keyed> forms to throw an exception. 
    9797 
     
    105105 
    106106=back 
    107107 
    108 =head3 C<_keyed> vtable methods 
     108=head3 C<_keyed> vtable functions 
    109109 
    110 So what of these magical C<_keyed> vtable methods? They are generated when you 
    111 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> 
     110So what of these magical C<_keyed> vtable functions? They are generated when 
     111you add the C<keyed> tag to the appropriate entry in F<src/vtable.tbl>. They 
     112are constructed by following B<every> C<PMC> argument with a second C<PMC> 
    113113argument which acts as the key for that argument; the name of the second 
    114114C<PMC> argument is formed by adding C<_key> onto the end of the first C<PMC> 
    115115argument. 
     
    123123 
    124124    $a = @b[$c] 
    125125 
    126 use the same vtable method, reducing the multiplicity of methods.  Secondly, a 
    127 three-argument C<assign> as suggested by the code above would be ambiguous - 
    128 the code above uses 3 PMCs in different ways. 
     126use the same vtable function, reducing the multiplicity of these functions. 
     127Secondly, a three-argument C<assign> as suggested by the code above would be 
     128ambiguous - the code above uses 3 PMCs in different ways. 
    129129 
    130130Also, operations which take an aggregate key for one of their arguments should 
    131131take aggregate keys for B<all> of their arguments. This is to avoid the 
     
    149149world situation are expected to be C<PMC>s anyway, this shouldn't be too much 
    150150of a problem. 
    151151 
    152 So, if you have a PMC in a C<_keyed> method which you don't want to index, 
    153 pass in C<NULL> instead of a real key. Code implementing these methods should 
     152So, if you have a PMC in a C<_keyed> function which you don't want to index, 
     153pass in C<NULL> instead of a real key. Code implementing these functions should 
    154154understand C<PMC* foo, PMC* NULL> as meaning the entirety of C<foo> in some 
    155155sense; this is trivial to understand if C<foo> is non-aggregate, and 
    156156implementation-defined if C<foo> is aggregate. If you remember that a key PMC 
     
    158158list, you'll reach a C<NULL> which again means the entirety of whatever object 
    159159you traversed to. 
    160160 
    161 Similarly, non-C<_keyed> methods on aggregates are implementation defined; for 
    162 instance, a C<set_integer> on a C<PerlArray> may be understood as setting 
     161Similarly, non-C<_keyed> functions on aggregates are implementation defined; 
     162for instance, a C<set_integer> on a C<PerlArray> may be understood as setting 
    163163C<@array.length>. 
    164164 
    165 Historically, we first implemented keys as two separate keyed methods per 
    166 applicable method - C<..._index> and C<..._index_s> for integer and string 
     165Historically, we first implemented keys as two separate keyed functions per 
     166applicable function - C<..._index> and C<..._index_s> for integer and string 
    167167indexing respectively. However, this didn't give us the flexibility and 
    168168scalability that key structures give us. 
    169169 
     
    296296=item Fri Mar  8 18:47:34 GMT 2002 : Version 1.1 
    297297 
    298298updated to reflect Dan's comments that non-aggregates also support C<_keyed> 
    299 variant vtable methods. 
     299variant vtable functions. 
    300300 
    301301=back 
    302302