You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When typeof_p_p is used to acquire a PMCProxy object describing a PMC class, the PMCProxy has inconsistent typing behaviour. typeof_s_p on it shows that it's a PMCProxy, but isa_i_p_sc claims both that it is a PMCProxy and (falsely) that it is of the class of the original object from which it was derived. typeof_p_p on the PMCProxy yields a PMCProxy that stringifies as the class name of the original object rather than as "PMCProxy".
Demonstration:
$ cat t11a.pir
.sub main :main
$P0 = new "BigInt"
$S0 = typeof $P0
say $S0
$P1 = typeof $P0
say $P1
$I0 = isa $P0, "BigInt"
say $I0
$I1 = isa $P0, "PMCProxy"
say $I1
say ":::"
$S1 = typeof $P1
say $S1
$P2 = typeof $P1
say $P2
$I2 = isa $P1, "BigInt"
say $I2
$I3 = isa $P1, "PMCProxy"
say $I3
.end
$ ./parrot t11a.pir
BigInt
BigInt
1
0
:::
PMCProxy
BigInt
1
1
Analogous things go wrong when acquiring the Class object describing a user-defined class. One additional thing goes wrong in my test: isa_i_p_sc claims that an object of a user-defined class isa Class.
Demonstration:
$ cat t11b.pir
.sub main :main
$P10 = newclass "Foo"
$P0 = new "Foo"
$S0 = typeof $P0
say $S0
$P1 = typeof $P0
say $P1
$I0 = isa $P0, "Foo"
say $I0
$I1 = isa $P0, "Class"
say $I1
say ":::"
$S1 = typeof $P1
say $S1
$P2 = typeof $P1
say $P2
$I2 = isa $P1, "Foo"
say $I2
$I3 = isa $P1, "Class"
say $I3
.end
$ ./parrot t11b.pir
Foo
Foo
1
1
:::
Class
Foo
1
1
Even weirder, if a '$I4 = isa $P0, "PMCProxy"' test is added into the above code, anywhere between setting $P0 and setting $P2, then the 'say $P2' yields the correct output "Class" instead of the incorrect "Foo".
-zefram
Summary of my parrot 5.5.0 configuration:
configdate='Sun Sep 22 18:01:32 2013 GMT'
Platform:
osname=linux, archname=x86_64-linux-gnu-thread-multi
The text was updated successfully, but these errors were encountered:
typeof_s_p on it shows that it's a PMCProxy, but isa_i_p_sc claims both that it is a PMCProxy and (falsely) that it is of the class of the original object from which it was derived.
Looking at the implementation, I can see where at least some of this bizarre behaviour comes from. The definition of the vtable method "isa_pmc" in class.pmc has some startling logic blunders. For a start, it checks whether the target class metaobject is the same object as the invocant, and returns true if they are. It therefore claims that X is-a X for all classes X; for example, claiming that my Foo class metaobject is-a Foo. Further down the same method it iterates over the superclasses of the class of the invocant, and asks each of them whether they are of the target class.
Generally, the code confuses is-a (is-an-instance-of) with is-a-subclass-of. There don't seem to be any methods (either in the vtable or in the method namespace) for asking whether one class is a subclass of another. Some such method is required, and the "isa_pmc" implementations should use it.
Reported by: zefram@fysh.org
When typeof_p_p is used to acquire a PMCProxy object describing a PMC class, the PMCProxy has inconsistent typing behaviour. typeof_s_p on it shows that it's a PMCProxy, but isa_i_p_sc claims both that it is a PMCProxy and (falsely) that it is of the class of the original object from which it was derived. typeof_p_p on the PMCProxy yields a PMCProxy that stringifies as the class name of the original object rather than as "PMCProxy".
Demonstration:
Analogous things go wrong when acquiring the Class object describing a user-defined class. One additional thing goes wrong in my test: isa_i_p_sc claims that an object of a user-defined class isa Class.
Demonstration:
Even weirder, if a '$I4 = isa $P0, "PMCProxy"' test is added into the above code, anywhere between setting $P0 and setting $P2, then the 'say $P2' yields the correct output "Class" instead of the incorrect "Foo".
-zefram
The text was updated successfully, but these errors were encountered: