Sam Ruby <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> Below inline attached is a proposal for vtable changes, mainly WRT >> method lookup.
> First, a general question: under what circumstances is it OK and/or > expected for the opcode C<getclass> and the VTABLE entry > VTABLE_get_class to return different results? No. The opcode should just call VTABLE_get_class() and return, what that method returns. > At the moment, these return quite different results for all of the > standard PMCs. The C<getclass> opcode currently returns, what the type registry C<class_hash> provides. This is ok for the standard PMCs, because the registered class is C<vtable->data>. But the opcode should just call VTABLE_get_class(). > The more general observation behind this question: if Parrot is going to > provide a mechanism by which a class can override get_class, then the > runtime should depend on such interfaces instead of bypassing them and > attempting to standardize on mechanisms. Yes. The proposed changes are one step towards that goal. I'd like to have a standard interface for classes, a default implementation for Parrot core PMCs and Parrot standard objects, and all the phases of class manipulation should of course be overridable, i.e. the individual methods are all called through vtable functions. > - Sam Ruby leo
