Simon Cozens:
# 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.
But to save memory space they'll use a preallocated one until something
gets overloaded, right?
# > 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.
I think I mentioned my idea of a good interface on language-dev:
a->v_add(a, b, c);
Or even better, we could do:
a->v_add(b, c);
and let either the XS-izer or process_op_func.pl (whichever this chunk
of code is being run through) transform that into
v_add(a, b, c);
That would just be the (Perl) line:
s{(\w+)->(v_\w+)\((.*?)\)}{$2($1, $3)}g;
And of course we would have to make sure we avoid struct members
starting with v_. I think we can do that. :^)
# 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.
You mean they put that nasty bit of code EVERYWHERE? Three problems
with that approach:
a. It's scary-looking and could freak out a newcomer.
b. It's easy to mistype.
c. It's too damn long!
# Sounds like a language-dev question; how best to handle
# method despatch
# on objects in C? Is it *really* a maintainability-speed trade-off?
With a preprocessor, that's how. :^)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
