Proposed vtable changes WRT method lookup
Sam Ruby
> 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?
At the moment, these return quite different results for all of the
standard PMCs.
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.
- Sam Ruby
Dave Whipp
> 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".
Its a minor thing, but I would try to avoid using identifiers that are
keywords in C++: especially in header files. The fact that Parrot is
pure C doesn't mean that no one will attempt to use a C++ compiler on it
in the next 20 years. I've been bitten by this sort of thing too many times.
Dave.
Leopold Toetsch
> Leopold Toetsch wrote:
>> 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".
> Its a minor thing, but I would try to avoid using identifiers that are
> keywords in C++: especially in header files.
Aren't struct members in a distinct namespace? It's like:
typedef struct _vtable {
...
PMC *class;
...
} VTABLE;
But it could of course read C<class_pmc> or such.
> Dave.
leo
Leopold Toetsch
> 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
Matt Fowles
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."
-???
Leopold Toetsch
> ... 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.
That was C<vtable->dispatch> in the proposal. C<find_method> is just
called to query one object or class, if it can do the method. Finding
the final (MMD) function is done separately with a distinct vtable
method (and probably implemented inside some meta class PMC).
> Hope that makes sense,
Yes.
> Matt
leo
Matt Fowles
That makes sense. If the vtable->dispatch method is attatched to some
PMC, what provides that PMC? Is it the MMD function being called
(what I would suggest), some environmental one, or something else?
Leopold Toetsch
> Leo~
> On Tue, 18 Jan 2005 16:52:52 +0100, Leopold Toetsch <l...@toetsch.at> wrote:
>> That was C<vtable->dispatch> in the proposal. C<find_method> is just
>> called to query one object or class, if it can do the method. Finding
>> the final (MMD) function is done separately with a distinct vtable
>> method (and probably implemented inside some meta class PMC).
> That makes sense. If the vtable->dispatch method is attatched to some
> PMC, what provides that PMC?
That PMC is the metaclass PMC of the class system. For standard Parrot
objects that's mostly default.pmc or parrotclass.pmc and/or an
implementation in src/objects.c.
> ... Is it the MMD function being called
> (what I would suggest), some environmental one, or something else?
Given a P6 function call (which can be MMD or not):
foo($a, $b, $c)
If nothing is kwnown about "foo", this would be basically:
func = a.dispatch("foo") # VTABLE_dispatch(interp, a, "foo")
invokecc func
That ends up in default.pmc's implementation normally, which calls
C<find_method> repeatedly according to C<vtable->mro> and the algorithm
described in "MMD and VTABLE_find_method".
> Matt
leo