At 6:17 PM +0100 12/30/02, Leopold Toetsch wrote:
When a PMC has been referenced by anything we can't move it. Because of potential introspective actions on the part of pretty much everything, PMCs need to be at a fixed address at creation time.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.
We could, I suppose, but I'd rather not if we can avoid it. (Though there are other issues with runtime properties, as I'm about ready for Larry to ask for lexically scoped dynamic runtime properties...) Let's keep it as-is for now, as it matches our expected general-use case (i.e. perl, python, ruby) best.... (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.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
