--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
> So we can get the damn thing nailed down and done. If there's
> something pending throw it on as a reply and we'll gather them up and
> see about making it work.
Someone conversant with the OO bits of the Python bytecode should do a
side-by-side feature comparison to see which way the pie is likely to
fly. (Not that urgent, but a similar exercise for the Java bytecode
wouldn't hurt overmuch.)
> So we can get the damn thing nailed down and done. If there's
> something pending throw it on as a reply and we'll gather them up and
> see about making it work.
I'd like to:
- pass arguments to a constructor (or initializer, or whatever you want
to call it) without calling a separate method explicitly. The BUILD
property Leo suggested looks like it'll work.
- free memory for external data from an object finalizer (or
destructor, or whatever you want to call it), again without calling a
separate method explicitly. Throwing a FINALIZE property on the class
looks like it'll also work. I don't need reliable time of destruction,
as long as it's not a slow memory leak.
- use nested namespaces properly, though what I have now will work for
now.
-- c
1) Done: [gs]etattribute do use vtable functions as pdd15 documents it,
as well as the getclass opcode. [1]
2) Todo: call BUILD and/or CONSTRUCT instead of __init
I've posted a working patch to get that running. If we change to that
scheme I'd rather have it in now then later--P6E2 deadline is coming
RSN.
3) Unsolved: diamond parent problem s. t/pmc/object-meths_17
leo
[1] We will probably need it for multi language interoperbility. It's
one more indirection, but saves an C<if> to test for a valid object.