On Wed, 18 Dec 2002, Leopold Toetsch wrote:
> David Robins wrote:
> > if(value->vtable == &Parrot_base_vtables[enum_class_Vec2D_in_Y_plane]) {
>
> always compare ids (vtables may change) - yes, many pmc's do like above,
> but will need changes too.
What do you mean by ids? pmc->type()?
> > PMC* ret = pmc_new(INTERP,enum_class_Vec3D);
> morph "dest" to be a "ret"?
> unimplemented, unused, but your examples seems to be a typical test case.
"dest" could be any type, so it's not reasonable to expect any type to be
able to morph to my chosen destination PMC type (unless default->morph can
be changed to do a standard new for the type).
> > if(dest->flags & PMC_active_destroy_FLAG)
> > dest->vtable->destroy(interpreter,dest);
> Just forget "dest", it will be collected when unused.
Alright, I was thinking about GC but wasn't sure about destroy, but of
course the GC should do that too.
> > *dest = *ret;
> Brr, will break for sure somewhere. PMCs might even be of different size
> - Not now, but who knows)
Sure, I recognize why it's evil (binary copy and all), it's just my first
approximation/guess at how it should be done. (And with the present
semantics it should work, but should be wrapped in a function/macro.)
The thing is that dest _must_ be changed somehow, because it's the only
return value (the function itself is void). Actually, *dest needs to be
changed, because of course the dest pointer itself is a copy.
Maybe the ops should instead be changed to be
PMC* binaryOp(PMC* rhs) and
PMC* unaryOp(void)
after all, most of the time _someone_ has to create a destination PMC, and
except for the reuse angle (and 'new' is probably quite fast), the PMC
handling the op is in the best place to do it. Any particular objections to
that? (I take it the PMC Px regs are just pointers, so it shouldn't involve
any copying.)
> leo
Dave
Isa. 40:31
