Hi,
Allison Randal wrote:
It looks like every low-level PMC is creating a proxy object for
itself and these proxies are stored in the interpreter global
parrot_interp_t.
That's what's implemented, yes. I pondered hanging them off the v-table
too. That's perhaps more desirable.
I intended that proxies would only be created when they were needed by
a subclassing Class PMC, and would only be stored in the Class PMC.
I don't think this is the way to go.
1) It'd be good to be able to use the get_class opcode with PMCs as well
as PDD15 classes. For that to Just Work, you need something hanging off
the class slot of the appropriate namespace. That something is the
PMCProxy. Thus it needs to be there from the start.
2) It's desirable that there is only ever one instance of PMCProxy per
PMC. Then "is this the same class" is just a case of checking the
pointers, as with PDD15 classes. Plus memory issues.
3) At the moment method lookup (for non-vtable methods, of course) is
done through the namespace. We moved away from that in PDD15 classes,
and with PMCProxy can do the same for methods of PMCs too. If you want
to be able to have a list of methods inside PMCProxy, you need it stored
somewhere runtime-accessible. If you're going to hang that data
somewhere, why not just make the PMCProxy in the first place and store
it in there.
4) PMCProxy also allows introspection of PMCs, not just placing them in
an inheritance hierarchy.
5) It's just less code complexity to create them up-front.
What was the motivation for having them instantiated lazily?
Looking at the code from another perspective, though, maybe what we've
got here is the beginning of an "HLLSubclassable" role that adds a
handful of Class methods to low-level PMCs.
I wander if we have different thoughts of what PMCProxy is supposed to
achieve. Here's what I thought: when you have a PDD15 class, you have
the instance of Class and you have the instance of Object. For PMCs, you
have the second of these - an instance of the PMC. PMCProxy fills in the
gap - it's like the Class PMC for PDD15, only for PMCs rather than PDD15
classes.
Ultimately all PMCs need to be able to respond to inspect_str.
Yeah, but there you're inspecting the object, not the class. Those are
different, I think?
And ultimately, all PMCs need to have an entry in their NameSpace so
the type IDs can go away entirely.
They already do, and by hanging PMCProxy off the class slot in the
NameSpace PMC, we're a step closer to that, if it's the Right Thing to do.
Thanks,
Jonathan
