The following PIR (attached as "script.pir", and also included here)
fails under Parrot 0.2.1 (Fedora Core 3, Intel x86):
.sub main @MAIN
$P1 = newclass "PARENT_1"
addattribute $P1, "foo" #1
$P2 = subclass $P1, "PARENT_2"
addattribute $P2, "foo" #2
$P3 = subclass $P2, "CHILD"
addattribute $P3, "bar"
$P0 = new "CHILD"
$P97 = new .String
set $P97, "Hello from attribute foo"
setattribute $P0, "foo", $P97 #3
$P98 = new .String
set $P98, "Hello from attribute bar"
setattribute $P0, "bar", $P98 #4
$P99 = getattribute $P0, "foo" #5
print $P99
print "\n"
end
.end
This prints "Hello from attribute bar" when it should print "Hello from
attribute foo".
The bug disappears if line #4 is commented out, suggesting that
"setattribute foo" (line #3) and "setattribute bar" (line #4) are both
storing into the same slot that is retrieved by "getattribute foo".
The bug also disappears if either line #1 or line #2 is commented out,
suggesting that this bug is exposed by multiple layers of inheritance.
Here's the inheritance hierarchy:
PARENT_1 # adds attribute 'foo'
^
|
PARENT_2 # adds attribute 'foo', hiding the inherited one
^
|
CHILD # adds attribute 'bar'
Regards,
Roger Browne
> Here's the inheritance hierarchy:
>
> PARENT_1 # adds attribute 'foo'
> ^
> |
> PARENT_2 # adds attribute 'foo', hiding the inherited one
> ^
> |
> CHILD # adds attribute 'bar'
The first question is of course:
a) should we fully hide PARENT_1's "foo"
b) or should the attribute still be accessible as "PARENT_1\0foo"
or: how many attributes has CHILD?
leo
> > PARENT_1 # adds attribute 'foo'
> > ^
> > |
> > PARENT_2 # adds attribute 'foo', hiding the inherited one
> > ^
> > |
> > CHILD # adds attribute 'bar'
>
> The first question is of course:
>
> a) should we fully hide PARENT_1's "foo"
> b) or should the attribute still be accessible as "PARENT_1\0foo"
>
> or: how many attributes has CHILD?
We also need to ask how many attributes CHILD has in the case of
multiple inheritance (where PARENT_1 and PARENT_2 both have attribute
'foo'):
PARENT_1 PARENT_2
^ ^
\ /
CHILD
I can live with either answer (from the point of view of implementing
the Amber compiler).
Regards,
Roger Browne