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

Allison Randal via RT wrote:
> Christoph Otto wrote:
>> 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.
> 
> This doesn't make sense. The PMC_x_val macros accessed the union value 
> of the PMC. Any PMC that used them had a fixed set of attributes, either:
> 
>   - a buffer
>   - two pointers
>   - two integers
>   - a float, or
>   - a string
> 
> Because it was a union value, the PMC could use one and only one of the 
> alternatives, and the parent and child had to use the same alternative. 
> So, when you're translating an old-style PMC to a new-style PMC, you'll 
> define one of:
> 
>   - a buffer
>        ATTR void *     _bufstart;
>        ATTR size_t     _buflen;
> 
>   - two pointers
>        ATTR DPOINTER * _struct_val;
>        ATTR PMC *      _pmc_val;
> 
>   - two integers
>        ATTR INTVAL _int_val;
>        ATTR INTVAL _int_val2;
> 
>   - a float
>        ATTR FLOATVAL _num_val;
> 
>   - a string
>      ATTR STRING * _string_val;
> 
> And hopefully give it a more meaningful name than the original.
> 
> Parent and child had to have the same struct in the original (because 
> every PMC defined the same union val struct), and so still have to have 
> the same struct in the new version. It is progress: at least the struct 
> members will have more meaningful names, and it will become possible to 
> subclass these older PMCs from within PIR. More progress will come later 
> with enhancements to inheritance, but that's no reason to hold up the 
> deprecation of the union struct.

So you're saying that multiple inheritance in its current state should be 
allowed to continue, and that there's only a problem with ATTRs if a PMC tries 
to extend two PMCs, both of which have their own ATTRs?
If this is the case, I'm happy.  The PMCs I've found which use multiple 
inheritance (LuaFunction, TclInt and TclFloat) all have one parent which 
appears to be a generic or abstract PMC type for that language (LuaAny and 
TclObject, respectively).  I'll get to work on a patch to propagate ATTRs to 
children and post it here when it gets close to ready.

> 
>> 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.
> 
> This is overkill. Accessor macros already work on PMCs similarly to how 
> PMC_x_val is used.
> 
> Allison
> 
> 

I agree and am glad that such a heavyweight solution is evitable.