Here are some thoughts:
1) Vtable and interfaces
The VTABLE structure provides common slots that every PMC must provide and optional parts that roughly correspond to an interface. E.g. a scalar doesn't need the array slots push, pop, shift, unshift ... But an array should fill these, but not the scalar entries like get_number.
Each of the optional interface parts in the VTABLE is just a pointer to a structure holding the entries (or to a default implementation that catches errors for unhandled interfaces) This adds one indirection to most of the vtable calls but it reduces the size of the vtable vastly.
2) Vtable entries should be real methods
All non-defaulted, non-inherited entries of a vtable interface should be available as methods, like now with the METHOD keyword. This allows eventually code like this:
Px = Py."__pop_pmc"()
or
Px = Py."__string"() # $x = ~$y string kontext
This easily allows overloading of all the vtable methods. The PIC code gets even rid of the additional indirection as the function is called directly from opcodes. The vtable slots are just for calling these methods from within C source.
3) MMD functions
They work basically like other methods except that there is no VTABLE slot and the method lookup is more complicated. The more detailed (and very preliminary) proposal below has some additional MMD functions that we'll need (IMHO):
"__i_add"(Px, Py) # $x += $y Px = "__n_add"(Py, Pz) # x = y + z ; x is newly created
The distinct slots for the inplace operations are at least necessary for Python, as these are separate methods in Python. It also simplifies the implementation as a check for "self == dest" isn't necessary in the plain operations.
The variants with an "n_" prefix create and return a new PMC.
Comments welcome. leo
=head1 TITLE
Vtable and Interfaces =head1 ABSTRACT Every PMC and Parrot Class has a distinct vtable. Additionally a shared or read-only variant of a PMC or class needs a different vtable. But by far not all vtable slots are used by all classes. To improve memory usage and flexibility this proposal describes a split of vtable functionality. =head1 DESCRIPTION A vtable gets split into different parts: common funtionality that each PMC must provide and optional interface parts. =head2 Common vtable entries =item instantiate, mark, destroy, finalize, freze, thaw ... =item type, mro, name, find_method, isa, does, can =item cmp, hash =head2 Scalar PMC entries =item add, subtract, multiply, ... MMDs ! Use an existing destination. =item nadd, nsubtract, nmultiply, ... MMDs ! Create a new destination. =item inc, dec =item iadd, isubtract, ... MMDs ! Inplace operations C< a += b >. =head2 Native scalar entries =item get_integer, get_number, ..., add_int, multiply_int ... =head2 PMC array entries =item get_pmc_keyed, push, pop, shift, unshift, splice =head2 Native array entries =item get_integer_keyed ... =head2 PMC hash entries =item get_pmc_keyed, exists_keyed, delete_keyed =head2 Native hash entries =item get_integer_keyed ... =head2 Object entries =item get_attribute, set_attribute, ... =head2 Iteration slots =item get_iter, iter_next
