Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typeof() and isa() inconsistencies #990

Open
Util opened this issue Oct 3, 2013 · 1 comment
Open

typeof() and isa() inconsistencies #990

Util opened this issue Oct 3, 2013 · 1 comment

Comments

@Util
Copy link
Member

Util commented Oct 3, 2013

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:

$ 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
@Util
Copy link
Member Author

Util commented Oct 5, 2013

I (zefram@fysh.org) wrote:

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.

-zefram

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant