On Sat, Oct 06, 2001 at 08:24:46AM -0500, Gibbs Tanton - tgibbs wrote:
> 1.) Will each different "type" of PMC have its own vtable, function
> definitions, etc or will they all share everything with switches on type in
> the function definitions.
They'll each have their own, to make overloading possible.
> 2.) Can you give an idea of what you think the macro-ized function should
> look like (an example would be great.)
No, because then you'll go away and implement it, and I want to encourage
some fresh blood to do that. :)
Seriously, before I do that, I need to seriously think about what vtable
accessors ought to look like;
(pmc1->vtable[want_vtbl_add])(pmc1, pmc2, pmc3)
is going to scare people away quickly, and, while
PMC_ADD(pmc1, pmc2, pmc3)
is cute, (and allows us to autogenerate Parrot byte ops ;) Macro
Hell is something we want to avoid.
For comparison, Python does stuff long-hand:
if (v->ob_type == w->ob_type
&& (f = v->ob_type->tp_compare) != NULL)
return (*f)(v, w);
so maybe it's not that bad. (In fact, look in Object/abstract.c for how
Python handles PMC vtable functions, uh, I mean, PyObject method calls.)
It's certainly easiest to understand, although the abstraction in
abstract.c might cost some running time. Or it might not. I always seem
to work on the assumption that "function calls are always very costly",
but that might not be true these days.
Sounds like a language-dev question; how best to handle method despatch
on objects in C? Is it *really* a maintainability-speed trade-off?
--
The angels want to wear my red shoes.
