On Wed, Sep 24, 2008 at 05:00:31PM -0700, jerry gay wrote:
> On Wed, Sep 24, 2008 at 4:31 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > They're not really methods in any PIR or C sense though (I usually use the
> > term "entry"), as they're not really inherited nor invoked through a
> > dispatch scheme [...]
> [...]
> i really wish the "vtable methods" meme would die. they're not
> methods. they are a collection functions which define the api to
> access the pmc, parrot's abstract data type.
I'm curious about the "not really inherited" part -- if I declare
a new PMC class with
pmclass MyString extends String provides string ... {
}
then doesn't the MyString PMC "inherit" the vtable entries from
String?
I grant that there may be reasons why this isn't truly "inheritance",
but I think the use of the keyword "extends" (c.f. Java) may be
what makes all of this look like classes and methods.
Similarly, VTABLE_get_integer(pmc) acts an awful lot like a
polymorphic dispatch mechanism, even if it's a very simplistic
one.
I'm not at all arguing that this automatically means we should call
them "methods", but at a conceptual level they certainly seem a lot
like methods, and the vtable implementations contain references to
things like SELF and STATICSELF that make them look awfully method-like.
Regardless, I'll be happy to call them entries, methods, functions
or whatever the consensus and documentation ends up saying they are. :-)
Pm
