There was already some discussion about splitting the VTABLE structure
into distinct pieces. I'd like to start that task after 0.1.2 is out.
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
[
VTABLE.txt 1K ]
=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
