I suppose PMC authors (or opcode authors?) should be pretty clear on whether they're re-using the same PMC or cloning up a new one.
The semantics of PMC operations have to be better documented. "The Book" has more examples on that.
But there are basically very simple and view rules:
- aggregates store references (aka pointers) to PMCs
- lexical pad ops and store_global too
- only (basically & AFAIK) these ops generate new PMCs:
new, newsub, clone, dlfunc, open, fdopen, rx_makebmp
- the keyed get operations get and refer to an existing PMC
- the OUT argument direction is an indication of one of above 2 behaviors
- all other PMC related ops need an existing PMC
The current behavior of getstd{in,out,err} delivering a new IO PMC is only a workaround to keep it running, this will change soon, you'll get a (constant) ref to a ParrotIO created at init time.
leo
