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

[ OBJ.txt 2K ]
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