Thomas Wouters:
# On Sat, Oct 06, 2001 at 09:44:29AM -0700, Brent Dax wrote:
#
# > 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. :^)
#
# How would that work without knowing the exact type of 'a' ? Unless you
# implement v_add as a bigass switching function that knows all
# types, or
# dereferences pointers itself -- winning you exactly nothing,
# and costing you
# a function, a few dereferences and a switch.
Well, there's always Dan's format:
#define v_add(a, b, c) (a->vtable[ADD + b->v_type() + c->v_type()])(a,
b, c) /*or something like that*/
OTOH, if we put all the argument intelligence into the vtable function
it's just:
#define v_add(a, b, c) (a->vtable->add)(a, b, c)
# Other than that, the idea of such an odd preprocessor grosses
# me out :) but
# I won't go into that unless it's a serious solution for a problem.
Maybe that scares people who haven't written Perl source filters, but
I'm not one of them so it doesn't scare me :^). Besides, it's only
scary to the person working on the preprocessor; it's intuitive to the
person using the preprocessor.
# > # 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);
#
# > 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!
#
# It's also an implementation issue. No-one extending or
# embedding Python
# writes code like that, they just write "PyObject_Compare(a,
# b)". That means
# several things:
#
# a. It's very simple looking and easy to remember
# b. It's easy to spot typos :)
# c. Interpreter internals such as object structs (Parrot
# PMC's) stay
# internal. You can import your module into a different
# version of
# Python that changed the entire inner working (or even
# started using
# Parrot :) and you don't even have to recompile.
#
# The only place that has the code snippet Simon pasted is the
# implementation
# of PyObject_Compare. Even other Python internals just call
# PyObject_Compare.
# If you want to know how well this works, please, read a few
# files in the
# Python sourcecode. It won't hurt.
Okay. From Simon's description it sounded like you did that wherever
you needed to call a PyObject_* function. Never mind then. :^)
# > # 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. :^)
#
# Standard C macro's are also handled with a preprocessor, but
# Simon already
# said he wanted to avoid macro-hell, right ? :)
I'm interpreting that statement as "I want to avoid Perl 5's
macro-hell". A whole different macro-hell, defined by us, would
therefore be okay. :^)
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
