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.
Re: [perl #48014] [DEPRECATED] PMC union struct
On Wednesday 21 January 2009 17:23:42 Christoph Otto wrote: > 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. We've never really supported C-level PMC multiple inheritance. As best I can figure, it was a quirk of the PMC preprocessor that allowed the appearance of multiple inheritance. Certainly the semantics have never been defined, at least as far as inheriting behavior or attributes. If C PMCs need to proclaim that they conform to the interface of another PMC, they should use 'does'. -- c
Re: [perl #48014] [DEPRECATED] PMC union struct
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.
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
