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.