David Robins wrote:
On Wed, 18 Dec 2002, Leopold Toetsch wrote:
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()?
Yes, ->vtable->type().
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).
In pdd02_vtables.pod morph() is defined to do exactly this.
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.
The question is, how often may a PMC be reused, and how often has it to be a new one. And for which vtable to you call above Op?.
The HL normally has smome rules, what the LHS has to be, so normally, you do a "new Px, .Type" for the LHS and you have already a PMC of the correct type. When the HL has different concepts, this might not be useful.
Dave
leo
