Dan Sugalski wrote:
At 11:45 AM +0100 12/30/02, Leopold Toetsch wrote:
A "simple" PMC would be a typical scalar (num or int) without properties. Attaching properties to such a PMC would need promoting it to a "complex" PMC.
We can't promote to a larger type, as that would require moving the PMC, and we've promised PMCs won't move. Otherwise I would.
Promoting would happen only with defined ops/functions like I<setprop>.
These would then have similar semantics to I<clone>.
But you are right: when a PMC is referenced inside an aggregate, we can't move it around.
... (And I don't want to go with an extra level of indirection for this, for speed reasons)
Nor do I.
But we could make the original PMC into a pointer (internal ref) to a newly created larger PMC which holds e.g. the property metadata. With the var/value vtable split in place, this operation would probably be easy by swapping the var.vtable part.
BTW: what is the reason, that PerlStrings are attached to the data member and not to cache.string_val? Caching int/num vals of strings?
Hysterical raisins, partially. The data pointer is supposed to point to the actual data, while the cache union has a cached converted version for fast later access.
Doesn't really matter, when we don't have differently sized PMCs. leo
