Leopold Toetsch wrote:
the basics are: * the destination PMC $1 is created by the opcode
I don't want to dwell on this point, but it would be rather handy if the caller were able to pass in an object which was responsible for producing the desired destination PMC on request.
It would accept requests like "give me an Integer" and would respond with things like "here's a PyInt".
At the moment, we have a fairly good approximation of this with VTABLE_morph. "Make yourself a BigInt"..."OK, (P.S. I'm really a PyLong)".
This won't work for languages which have a notion of singletons, unless the language uses a double-reference system... like Ruby and Perl 5 do today (per Dan's previous statements).
Python's None is a singleton. False and True should be, but for compatiblity reasons this wasn't changed (yet). There's old code around that does:
False, True = 0, 1
Anyway disallowing singletons as return results is major drawback of the current scheme.
Second: we have two different function signatures: overridden methods are returning new PMCs. Internal methods currently get the destination PMC. We'd need glue code to translate between these two schemes.
And there are of course performance considerations:
Px = new Undef add Px, Py, Pz
If "add" is overridden, we are preconstructing a PMC for nothing. That increases pressure on GC. And morphing the Undef (or whatever) is a rather expensive operations - look at pmc.c:pmc_reuse().
WRT constructing the new type: Given that PyInt_add_PyInt is inherited from the Integer PMC, it should work if we do:
dest = pmc_new(interp, SELF->vtable->base_type); VTABLE_set_integer_native(interp, dest, sum); return dest:
When e.g. a BigInt is created due to overflow, we could to
dest = pmc_new(interp, SELF->vtable->base_type); VTABLE_set_bigint(interp, dest, left); VTABLE_inplace_add(interp, dest, right); // d += r return dest;
Additionally it wouldn't harm, if there is a list of basic types per supported language, so that a destination of the HLL's flavor can be constructed.
leo
