Patrick R. Michaud wrote:
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. :-)
They're all executable code entities of one sort or another. It's mainly a matter of choosing names that clearly mark different things as different. I picked "vtable functions" because they're directly invoked C function pointers (even the PIR vtable overrides are C function pointers that then do an override lookup). This differentiates them from from "methods" which are sub-like objects that take an invocant argument passed separately from the other arguments, are stored in the Class object, and can be invoked using the obj.'method'() syntax.
There are plenty of other possible naming schemes, but this one works well enough for our purposes.
Oh, and "vtable entries" was another common old way of referring to them, but I've been updating those to "vtable function" too, because "entry" seems a little vague (though, it's technically accurate, because the "vtable" is a whole set of functions (a "table" of functions) for the PMC, so a single vtable function is an entry in that vtable).
Allison
