Discussion:
[perl #48014] [DEPRECATED] PMC union struct
(too old to reply)
Will Coleda
2007-12-01 22:23:00 UTC
Permalink
# New Ticket Created by Will Coleda
# Please include the string: [perl #48014]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=48014 >


from DEPRECATED.pod

The PMC union struct is deprecated and will be removed once all core PMCs
have
been updated.
Will Coleda via RT
2008-03-26 04:01:41 UTC
Permalink
Post by Will Coleda
from DEPRECATED.pod
The PMC union struct is deprecated and will be removed once all core PMCs
have
been updated.
This has happened, correct?

Some pointers on how to implement this would probably turn this into a decent CAGE task...
Chromatic
2008-03-26 04:30:15 UTC
Permalink
Post by Will Coleda via RT
Post by Will Coleda
from DEPRECATED.pod
The PMC union struct is deprecated and will be removed once all core PMCs
have been updated.
This has happened, correct?
Not yet. PDD 17 made this possible, but someone (and your first two guesses
don't count) has to update all of the core PMCs and the language PMCs not to
use the cache structure.
Post by Will Coleda via RT
Some pointers on how to implement this would probably turn this into a decent CAGE task...
1) Figure out what kind of data the PMC stores
2) Replace all uses of PMC_int_val(), PMC_float_val(), and PMC_str_val() with
attribute access within the PMC
3) Replace all uses of those macros with attribute access outside of the PMC
4) Fix any compilation errors

-- c
Jerry Gay
2008-03-26 11:27:42 UTC
Permalink
Post by Chromatic
Post by Will Coleda via RT
Post by Will Coleda
from DEPRECATED.pod
The PMC union struct is deprecated and will be removed once all core PMCs
have been updated.
This has happened, correct?
Not yet. PDD 17 made this possible, but someone (and your first two guesses
don't count) has to update all of the core PMCs and the language PMCs not to
use the cache structure.
Post by Will Coleda via RT
Some pointers on how to implement this would probably turn this into a
decent CAGE task...
1) Figure out what kind of data the PMC stores
2) Replace all uses of PMC_int_val(), PMC_float_val(), and PMC_str_val() with
attribute access within the PMC
3) Replace all uses of those macros with attribute access outside of the PMC
4) Fix any compilation errors
to that end, a patch that spews warnings within those macros with
file/line info would be a great help. i'll code one up when i get a
chance, which will likely not be soon. feel free to beat me if you
find it helpful. i'd like very much to have this conversion done by
the next release.
~jerry
Allison Randal via RT
2008-07-03 21:12:03 UTC
Permalink
A bit more detail on the conversion process for a PMC:

1) Find the core data of the PMC, and convert it into a series of ATTR
statement at the beginning of the "pmclass" block. So, if the PMC uses
only 'PMC_int_val', create a single entry: 'ATTR INTVAL integer_data;'
(Pick a meaningful name, and add a comment at the end of the line
explaining what it is. A good example is src/pmc/eventhandler.pmc.)

If the core data of the PMC is a whole struct stored in PMC_data, you
can directly copy the body of that struct into the .pmc file, and just
prepend ATTR to each line.

2) Change any calls to PMC_int_val (or whatever macro the particular PMC
uses) to 'GET_ATTR_integer_data' or 'SET_ATTR_integer_data' (the
lower-case half of the accessor macros matches the name you gave the
attribute in the 'ATTR' declaration.) If your attribute is a
PMC/STRING/INTVAL/FLOATVAL type, the accessor is generated to correctly
set/retrieve the native type directly. These macros must be used on a
separate line, and can't be embedded within other C code on a line. See
src/pmc/exporter.pmc for an example. So this is correct:

GET_ATTR_ns_src(interp, SELF, tmp_ns_src);

but this is wrong:

tmp_ns_src = GET_ATTR_ns_src(interp, SELF);

3) Change 'init' and 'init_pmc' to initialize the auto-generated struct
instead of whatever initialization it was doing before. For example, if
it was previously setting a default value in PMC_int_val, it now needs
to allocate a struct of the appropriate type (the autogenerated structe
is always named Parrot_<PMCname>, so the Exporter PMC has a struct named
Parrot_Exporter), store that struct in PMC_data, and then set default
values on the struct. See src/pmc/exporter.pmc for a good example of
'init'.

4) Any place you need to directly access the core struct of the PMC, use
the accessor macro for the PMC's struct. It is named the same as the
struct but in all caps (for example, the Exporter PMC's accessor macro
for the core data struct used like 'Parrot_Exporter *core_struct =
PARROT_EXPORTER(SELF);').

5) Change 'destroy' to destroy PMC_data.

6) Change 'mark' to mark any PMC elements of the core data struct.

7) Check 'freeze'/'thaw' and related vtable entries for direct access to
old data elements and update it to the new data elements.

That should get you 90-95% of the way there. Rebuild the PMC (make sure
the src/pmc/pmc_<PMCname>.h header file for the PMC was regenerated to
include the Parrot_<PMCname> struct GETATTR and SETATTR macros). Check
for compile errors and test failures. If the cause of any errors isn't
immediately obvious, check with allison or chromatic.

Allison
NotFound
2008-07-11 16:40:56 UTC
Permalink
On Thu, Jul 3, 2008 at 11:12 PM, Allison Randal via RT
(snip)
Post by Allison Randal via RT
3) Change 'init' and 'init_pmc' to initialize the auto-generated struct
instead of whatever initialization it was doing before. For example, if
it was previously setting a default value in PMC_int_val, it now needs
to allocate a struct of the appropriate type (the autogenerated structe
is always named Parrot_<PMCname>, so the Exporter PMC has a struct named
Parrot_Exporter), store that struct in PMC_data, and then set default
values on the struct. See src/pmc/exporter.pmc for a good example of
'init'.
There is a problem with the autogenerated name: in several cases there
are other things with that name. For example, for the float.pmc we
have the Parrot_Float type defined in include/parrot/config.h

Given that the name will be mainly used via macros, a long and
meaningful name can be used, such as Parrot_PMCdata_<PMCname>
--
Salu2
Allison Randal via RT
2008-07-14 00:31:53 UTC
Permalink
Post by NotFound
There is a problem with the autogenerated name: in several cases there
are other things with that name. For example, for the float.pmc we
have the Parrot_Float type defined in include/parrot/config.h
Given that the name will be mainly used via macros, a long and
meaningful name can be used, such as Parrot_PMCdata_<PMCname>
That's a good refinement, we can make the change after the next release.

Allison
Allison Randal
2008-09-08 08:47:13 UTC
Permalink
Post by Allison Randal via RT
Post by NotFound
Given that the name will be mainly used via macros, a long and
meaningful name can be used, such as Parrot_PMCdata_<PMCname>
That's a good refinement, we can make the change after the next release.
The attached patch does it. There is a lot of changes, I suspect many
of them are candidates for replacing with use of the SET_ATTR and
GET_ATTR macros. Maybe defining a macro SELF_DATA_TYPE will be a
convenient shortcut.
Reading through the updated code, it seems that (using "Task" as an
example):

Parrot_PMCdata_Task

is not much clearer than the original "Parrot_Task" was. Let's go with:

Parrot_Task_attributes

(Fortunately, with the string "PMCdata" in all the type names, it should
be easy to write an automatic search-and-replace.)
I only modified and tested parrot core, surely several languages needs
some patching. Also, don't fixed line length codingstd. I expect
approval before taken care of that,
Otherwise approved, and thanks!

Allison
NotFound
2008-09-08 19:19:41 UTC
Permalink
Post by Allison Randal
Reading through the updated code, it seems that (using "Task" as an
Parrot_PMCdata_Task
Parrot_Task_attributes
A fast ack'ing of: Parrot_[_a-zA-Z]+_attributes for possible
collisions shows only:
Parrot_Class_nci_attributes
Parrot_Role_nci_attributes

We can live with this.
Post by Allison Randal
(Fortunately, with the string "PMCdata" in all the type names, it should be
easy to write an automatic search-and-replace.)
That was the main reason for using a long ugly name.
--
Salu2
NotFound
2008-09-08 20:58:43 UTC
Permalink
Post by Allison Randal
The attached patch does it. There is a lot of changes, I suspect many
of them are candidates for replacing with use of the SET_ATTR and
GET_ATTR macros. Maybe defining a macro SELF_DATA_TYPE will be a
convenient shortcut.
Reading through the updated code, it seems that (using "Task" as an
Parrot_PMCdata_Task
Parrot_Task_attributes
(Fortunately, with the string "PMCdata" in all the type names, it should be
easy to write an automatic search-and-replace.)
I only modified and tested parrot core, surely several languages needs
some patching. Also, don't fixed line length codingstd. I expect
approval before taken care of that,
Otherwise approved, and thanks!
Done in r30914: changed name to Parrot_<type>_attributes, fixed
codingstd, changed also pmc in languages lua and perl6, and updated
pdd17_pmc.pod
--
Salu2
Bernhard Schmalhofer via RT
2008-10-22 16:28:38 UTC
Permalink
Post by NotFound
Done in r30914: changed name to Parrot_<type>_attributes, fixed
codingstd, changed also pmc in languages lua and perl6, and updated
pdd17_pmc.pod
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
--
/* ***@gmx.de */
NotFound
2008-10-23 15:53:31 UTC
Permalink
On Wed, Oct 22, 2008 at 6:28 PM, Bernhard Schmalhofer via RT
Post by Bernhard Schmalhofer via RT
Post by NotFound
Done in r30914: changed name to Parrot_<type>_attributes, fixed
codingstd, changed also pmc in languages lua and perl6, and updated
pdd17_pmc.pod
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
No, this was just a helper step.
--
Salu2
chromatic
2008-11-05 21:03:47 UTC
Permalink
Post by Bernhard Schmalhofer via RT
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
Not until we apply this patch and all tests still pass.

-- c
Vasily Chekalkin
2008-11-06 20:52:38 UTC
Permalink
Post by chromatic
Post by Bernhard Schmalhofer via RT
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
Not until we apply this patch and all tests still pass.
Looks like you missed few lines from this patch. Few thousand lines :)
--
Bacek
chromatic
2008-11-06 21:11:38 UTC
Permalink
Post by Vasily Chekalkin
Post by chromatic
Not until we apply this patch and all tests still pass.
Looks like you missed few lines from this patch. Few thousand lines :)
This patch is necessary, but not sufficient!

Anyone who does want to help though should apply this patch, then start fixing
compilation errors.

-- c
Vasily Chekalkin
2008-11-06 20:48:43 UTC
Permalink
Post by chromatic
Post by Bernhard Schmalhofer via RT
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
Not until we apply this patch and all tests still pass.
Looks like you've missed few lines from this patch. Few thousand lines :)
--
Bacek
Will Coleda
2009-01-14 03:19:50 UTC
Permalink
On Tue, Jan 13, 2009 at 10:17 PM, Will Coleda via RT
Post by chromatic
Post by Bernhard Schmalhofer via RT
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
Not until we apply this patch and all tests still pass.
-- c
I removed one definition (PMC_str_val) locally and tried to fix the build. made some decent
progress: I assume that the replacement for this define and direct struct access are the
corresponding vtable entries; One problem, string.pmc's set_string_native uses the macro to
set its own value; How do I replace it there?
--
Will "Coke" Coleda
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Nevermind; I just saw allison's in depth explanation earlier in the
ticket history. (And that cotto claimed this ticket a scant 16 hours
ago so I can ignore it! =-)
--
Will "Coke" Coleda
Christoph Otto
2009-01-16 23:44:18 UTC
Permalink
I'm running into a snag trying to implement this. It turns out that
many lines which use the PMC_x_val macros use them on different types of
PMCs, especially parents and children (e.g. FixedPMCArray and
ResizablePMCArray). There are also some instances where the PMCs with a
related purpose but no inheritance (e.g. RetContinuation and
ExceptionHandler) have the unionval used in the same way on a line of code.
What's the right way to fix these cases to use the GETATTR/SETATTR macros?
I have a file that lists these, which I'll be sticking on the wiki later
tonight.
Here's the more detailed version:

Thanks to Infinoid++, I was able to follow particle's recommendation earlier
in the thread and modify the PMC_x_val macros to record some information at
runtime. This will make the cage task *much* more approachable and
parallelizable, but it also exposes places where code makes promiscuous
assumptions about PMC internals.

The referenced files were generated by modifying include/parrot/pobj.h [1],
then building and testing Parrot and any currently maintained HLLs that use
custom PMCs. The results are on trac, sorted by file [2] and by PMC [3]. I
did this to help clarify how the UnionVal macros would need to be converted to
GETATTR/SETATTR macros, since the latter are PMC-specific. The files are
generated from r34501 and can be regenerated as needed.

The problem with using ATTRs in their current state is that, depending on
control flow, a given instance of a PMC_x_val may be called with several
different PMC types (see src/hash.c:1045 in [2] for an extreme case). This is
fairly common and makes ATTRs unusable for any PMCs whose UnionVals are
twiddled by common code.

One solution to this would be to make ATTRs follow the inheritance chain so
the following code works:

PMC *foo = new_pmc(INTERP, enum_class_Foo); /*Foo has no ATTRs, extends Bar*/
INTVAL baz; /*Bar has a "baz" ATTR*/
GETATTR_Bar_baz(INTERP, foo, baz);


I'm not attached to any particular solution, but it's clear that the migration
away from the PMC UnionVal can't happen without some kind of significant change.


[1] http://xrl.us/becsw4 (diff)
[2] http://xrl.us/becswu (csv, sorted by source code file)
[3] http://xrl.us/becsww (csv, sorted by PMC type)
Christoph Otto
2009-01-18 09:44:03 UTC
Permalink
I'm running into a snag trying to implement this. It turns out that
many lines which use the PMC_x_val macros use them on different types of
PMCs, especially parents and children (e.g. FixedPMCArray and
ResizablePMCArray). There are also some instances where the PMCs with a
related purpose but no inheritance (e.g. RetContinuation and
ExceptionHandler) have the unionval used in the same way on a line of
code.
What's the right way to fix these cases to use the GETATTR/SETATTR
macros?
Tough to answer without looking at the code, but... The
GET_ATTR/SET_ATTR macros will work on inherited attributes as well as
child attributes. (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.)
If two unrelated PMCs are being called in the same line of code, that
probably means it should really be a vtable function call instead of
direct access into the data struct.
Allison
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.

For example, say that I add ATTR INTVAL struct_size; to UnManagedStruct. It's
possible to replace some instances of PMC_int_val with VTABLE_get_integer in
these two PMCs, but I can't use GETATTR_UnManagedStruct_struct_size in
UnManagedStruct's get_integer VTABLE function because ManagedStruct uses
UnManagedStruct's get_integer, but doesn't have its ATTRs.

It would be possible to add the same ATTR to ManagedStruct and make sure that
it had its own get_integer VTABLE function. Unfortunately this would mean
more code duplication and would negate some of the benefits of allowing PMCs
to extend each other.

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.
Christoph Otto
2009-01-22 01:23:42 UTC
Permalink
Post by Christoph Otto
(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.)
Post by Christoph Otto
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.
Chromatic
2009-01-22 02:02:54 UTC
Permalink
Post by Christoph Otto
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
Christoph Otto
2009-01-22 08:57:40 UTC
Permalink
Post by Christoph Otto
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
- 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
- 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.
Post by Christoph Otto
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
#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.
Bernhard Schmalhofer
2009-01-22 11:16:05 UTC
Permalink
The attached patch implements this behavior and fixes two core PMCs
that had been doing the inheritance manually. All tests in make test
pass. I didn't bother testing any HLLs as this is more of a "here's
what I'm thinking" patch, but it's not likely there will need to be
any changes other than nuking a few more now-redundant ATTRs.
Obviously, the HLLs will get a test before this gets committed,
barring any other objections.
+ #prepend parent ATTRs to this PMC's ATTR list
+ if (@{$pmc->{parents}} > 0 && $pmc->{parents}[0] ne 'default') {
+ my $got_attrs_from = '';
+ foreach my $parent (@{$pmc->{parents}}) {
+ my $parent_dump = $pmc2cMain->read_dump(lc($parent).'.dump');
+ if ($got_attrs_from ne '' && $parent_dump->{has_attribute}) {
+ die "$filename is trying to extend $got_attrs_from and $parent, ".
+ "but both these PMCs have ATTRs.";
+ }
+ if ($parent_dump->{has_attribute}) {
+ $got_attrs_from = $parent;
+ foreach my $parent_attrs (@{$parent_dump->{attributes}}) {
+ $pmc->add_attribute($parent_attrs);
+ }
+ }
+ }
+ }
+

I am wondering about the check with check with $got_attrs_from.
How is the case handled, where an PMC 'child' inherits from the PMC 'parent'
and 'child' wants to add an attribute to the attributes inherited from
'parent' ?

Regards,
Bernhard
Christoph Otto
2009-01-22 12:03:13 UTC
Permalink
Post by Bernhard Schmalhofer
The attached patch implements this behavior and fixes two core PMCs
that had been doing the inheritance manually. All tests in make test
pass. I didn't bother testing any HLLs as this is more of a "here's
what I'm thinking" patch, but it's not likely there will need to be
any changes other than nuking a few more now-redundant ATTRs.
Obviously, the HLLs will get a test before this gets committed,
barring any other objections.
+ #prepend parent ATTRs to this PMC's ATTR list
+ my $got_attrs_from = '';
+ my $parent_dump = $pmc2cMain->read_dump(lc($parent).'.dump');
+ if ($got_attrs_from ne '' && $parent_dump->{has_attribute}) {
+ die "$filename is trying to extend $got_attrs_from and $parent, ".
+ "but both these PMCs have ATTRs.";
+ }
+ if ($parent_dump->{has_attribute}) {
+ $got_attrs_from = $parent;
+ $pmc->add_attribute($parent_attrs);
+ }
+ }
+ }
+ }
+
I am wondering about the check with check with $got_attrs_from.
How is the case handled, where an PMC 'child' inherits from the PMC 'parent'
and 'child' wants to add an attribute to the attributes inherited from
'parent' ?
Regards,
Bernhard
Currently, there are no PMCs which multiply inherit from parents where more
than one parent has ATTRs. As far as I know, this currently falls under the
"don't do that" category.

The case where a child wants to have some ATTRs in addition to the ones its
parent has is handled gracefully. That's why the patch removes some ATTRs
from a couple PMCs. A child's ATTRs are a strict superset of the parent's.
Loading...