Various issues with get_class interface

[pmichaud]

The get_class opcode doesn't deal well with finding classes using an array, and there are other inconsistencies. Here are some:

(1) PDD15 is inconsistent about the mechanisms available to identify a class PMC. In various places it says:

• class object, namespace object, key, or string name PMC (isa, line 349)
• classname, namespace, or key PMC (get_attr_keyed, line 655)
• class object or namespace key (setattribute, line 951)
• PMC key or namespace object (get_class, line 1034)
• string PMC, namespace key, class object (new, line 1067)

Notably, nowhere does it allow an array to be used to identify a class, although the code does try to allow it (src/oo.c:188) and we allow namespace lookups via arrays.

Ideally I think we ought to be able to identify a class by any of

(a) class object, (b) NameSpace PMC, (c) Key PMC, (d) String PMC.

(2) Looking up a nonexistent class with a String PMC produces a null PMC (correct), but looking up a nonexistent class with an array produces a "get_string() not implemented in class 'ResizableStringArray'" exception:

    $ cat x.pir
    .sub main
        $P0 = box 'NoSuchClass'
        $P1 = get_class $P0
        $I1 = isnull $P1
        say $I1

        $P0 = split '::', 'NoSuchClass'
        $P1 = get_class $P0
        $I1 = isnull $P1
        say $I1

    .end

    $ ./parrot x.pir
    1
    get_string() not implemented in class 'ResizableStringArray'
    current instr.: 'main' pc 15 (x.pir:8)
    $

(2) Even when using an array that does support get_string(), we end up looking up the wrong class:

    $ cat y.pir
    .sub main
        $P99 = newclass '3'

        $P1 = new 'ResizablePMCArray'
        push $P1, 'A'
        push $P1, 'B'
        push $P1, 'C'
        $P0 = get_class $P1    # get class ['A';'B';'C']
        $I0 = isnull $P0
        say $I0

        # what class did we get?
        say $P0
    .end

    $ ./parrot y.pir
    0
    3
    $

Pm

[whiteknight]

More information about the issue here:

 http://lists.parrot.org/pipermail/parrot-dev/2009-January/000872.html

I'll start tackling this issue since I think it's important to standardize the get_class interface before I start messing with the VTABLE_morph interface (the two really should have identical ways to specify a class).

[whiteknight]

I'm decently certain that this issue is mostly fixed. The two examples that pmichaud posted above now act the way I would expect them to act. The first prints "1\n1", and the second throws an exception because the given class can't be found because it doesn't exist.

The internals are still a little hacky because Roles aren't handled properly. However, all the rest of the data items aren't stringified first which is something pmichaud said was bad. So, Roles are the only PMCs that are still handled that way, but we can redo their handling later when we run into problems for it. Issue resolved.