Below is mainly a repost of the old proposal.
Two additions:
7) all object opcodes should go through the vtable. From there the implementation can either call into Parrot's default (src/objects.c) or do whatever the class system needs.
8) attribute access
We currently have:
8.1) via classoffset and index
The index serves as a cache located in the bytecode. But there is no means to invalidate that chache, if the class (or one of the base classes) changed the layout. I don't know if a class can change under the code, but given that we support highly dynamic languages it's not unlikely that this can happen.
8.2) by fully qualified classname
The classoffset opcode needs the class name of the object, where the attribute is located. The named access needs a fully qualified attribute name with the class name inside.
That's probably ok for Perl6 as attributes are only visible in the class defining them (IIRC) but it doesn't work for Python. This seems to cause a problem for HLL interoperbility.
I think, we should do:
- toss the indexed attribute access - allow unqualified attribute names:
attr = getattribute obj, "attr_name"
would (in the default implementation) return the first matching attribute in the objects MRO. A full qualified name "class_name\0attr_name" could still be used, if needed.
Performance considerations:
A class system can implement the (new) vtable:
ptrdiff_t get_attribute_offset(...)
which returns the offset of the attribute location relative to the object. This offset can be cached in the PIC, which gives instant access to the attribute from the opcode run loop.
Comments? leo
Proposed vtable changes WRT method lookup
1) rename vtable->data to vtable->class
All current usage of the 'void *data' vtable element is as the object's
class. So it should read "PMC *class".
2) add vtable->mro - an array-ish PMC of classes
'PMC *mro' is a list of class PMCs - the "method resolution order".
mro[0] := this class
mro[1] := first parent
...
This replaces the current classsearch_array PCD_ALL_PARENT for real
objects. Additionally plain PMCs can place their parent classes here
so that the distinction of PMCs vs objects vanishes, when it comes to
method lookup.
3) add vtable->methods - an hash PMC of method_name => sub_PMC
mappings
Currently the methods of a class are stored inside Parrot globals in a
namespace "\x0$class_name". I think the proper place for method
storage should be inside the class itself.
This has some nasty implications though. When reading a packfile with
a Sub PMC inside a namespace this class might not exist yet. So
probably a bare class with just the method hash is pre-created.
4) add vtable->dispatch
This vtable method does the full method lookup and returns the
callable subroutine object, if any. It's basically what the current
VTABLE_find_method is doing.
PMC* dispatch(STRING* meth_name) {}
Find a method for invocant C<self> and arguments set according to
pdd03 to handle the given method. Return a Sub PMC or NULL.
The default implementation calls C<find_method> repeatedly for classes
in C<mro> until a proper method is found. It's likely that it also has
to look into lexicals for local overrides.
5) change vtable->find_method
It get's one additional argument C<INTVAL mmd_nr> as described in the
subject "MMD and VTABLE_find_method". The difference to that proposal
and to the current implementation is, that C<find_method> just
returns, if *that very* object (probably via its class) can do the
method or not. The search inside parents is handled by
C<vtable->dispatch>.
So we'll have:
PMC* find_method(STRING* meth_name, INTVAL mmd_nr) {}
return a Sub PMC or NULL, if the object C<self> can handle the given
method, where C<self> is the C<mmd_nr>-th argument in the call.
6) remove vtable->can
This is redundant, AFAIK. If C<dispatch> (or currently C<find_method>)
returns != NULL then C<can> is true else it's false.
Comments welcome,
leo
