Re: [perl #48014] [DEPRECATED] PMC union struct

Allison Randal via RT wrote:
> Christoph Otto wrote:
>> Allison Randal wrote:
>>> (Actually, at the moment you're required to declare 
>>> all parent attributes in the ATTR list before the child attributes, so 
>>> inherited attributes *are* child attributes.)
>> When I say "attributes", I mean the things that are declared in .pmc 
>> files right after the pmclass line, e.g.
>> ATTR INTVAL foo_refs; /*foo refcount*/
>> These do not appear to be passed down to extending PMCs.  This is a 
>> problem for e.g UnManagedStruct/ManagedStruct, where PMC_int_val is used 
>> the same way by both PMCs.
> 
> Right, at the moment it is absolutely required that the first ATTR 
> declarations of the child are manual copies of the ATTR declarations of 
> the parent. Otherwise, the inheritance won't work at all. (Ultimately, 
> inheritance will automatically copy the parent's attributes and prepend 
> them onto the front of the child's attribute list, but at the moment it 
> has to be done manually.)
> 
>> What I'd like is for the pmc2c code to be smart enough to make ATTRs 
>> from an extended PMC accessible by an extending PMC through the 
>> GET_ATTR/SET_ATTR macros.  If I could get a description of how such a 
>> patch should behave from our architect, I'd be glad to write one up and 
>> submit it for review.
> 
> The fix actually goes in a different place. The GET_ATTR/SET_ATTR macros 
> will be correctly generated for all child attributes. What really needs 
> to change is to add the parent's attribute list to the child's attribute 
> list during PMC parsing in Pmc2c. Take a look at 
> lib/Parrot/Pmc2c/Parser.pm. (I can give more specific guidance after the 
> release, working on milestone items at the moment.)
> 
> Allison
> 
> 

The PMC UnionVal deprecation can't be completed until Parrot has improved ATTR
reuse between extending PMCs.  I'm rewriting code to minimize dependence on
the PMC_x_val macros, but I can't eliminate them completely without better
inheritance support.  I'd like to implement whatever the long-term solution 
is, which seems to mean multiple inheritance regarding ATTRs.

I've been puzzling over how to implement this in a way that would work 
similarly to the current PMC_x_val macros.  The problem with allowing multiple 
inheritance is that we can't simply copy ATTRs from parents into the same slot 
in their children when multiple parents have an ATTR in the same slot.

The best I've been able to come up with is to use yet another Hash to store 
the ATTRs, turning the GETATTR/SETATTR macros into something like the 
following (modulo supporting code):
#define GETATTR_PMCType_foo(interp, pmc, x) {
   x = (AttrTypeGoesHere)parrot_hash_get(interp, pmc->attr_hash,
        key_new_cstring(interp, "PMCType_foo"));
}

This would allow the accessor macros to work on PMCs similarly to how 
PMC_x_val is used now, i.e. they'll DTRT as long as the PMC is in the right 
inheritance tree.
The obvious downside is that this is a major increase in runtime cost for 
something that's currently a pointer deref and a struct offset calculation. 
If there's a cheaper way to implement this and still support C-level PMC ATTR 
multiple inheritance, I'll be thrilled to implement it.

Either way, something needs to be done.