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.
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.
> # 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.
> # 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 ? :)
Pythonic-ly y'rs,
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
