All~ On Tue, 18 Jan 2005 10:18:52 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > 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.
It looks like we are creating ourselves a reasonable subset of the Common Lisp Object System here. Given that CLOS was created to allow Lisp programs to modify their objects' semantics to those of a different dialect of Lisp, perhaps we could learn from their structure. We have an mro array just like CLOS, we have a class PMC just like CLOS. If we add to it support. MMD, however, is where things begin to differ. Instead of havng the find_method with the extra mmd_nr, we could have a MMD_Resolution PMC which would then get the mro from each class, and figure out which method to call based on that. Logically this would make some sense as no single class can have the smarts to do MMD since it depends on all objects involved. This also allows each MMD function to dispatch according to the language which defined the function (and thus the MMD_Resolution PMC for that function). Hope that makes sense, Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
