At 07:13 PM 10/6/2001 +0200, Thomas Wouters wrote:
>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.
v_add is definitely not going to be a nasty switch. Yech. Instead there'll
be several add entries which we use based on the type of the second
argument, one for integer, one for big integer, one for float, one for
bigfloat, and one for everything else. The everything else entry can either
punt (and just fetch whatever data it wants from the second argument) or
whip through a multimethod dispatch table. (I've some clever algorithms to
make multimethod dispatch fast, courtesy of the kind folks at MIT)
>It's also an implementation issue. No-one extending or embedding Python
>writes code like that, they just write "PyObject_Compare(a, b)".
As will the folks extending Parrot. (Though odds are it'll be
Parrot_Compare or something, but if we can manage at least partial source
compatibility with Python extensions I'll be happy. Wildly surprised, too,
but that's OK. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
