Ticket #8 (closed todo: fixed)

Opened 5 years ago

Last modified 5 years ago

Various issues with get_class interface

Reported by: pmichaud Owned by: whiteknight
Priority: major Milestone: 0.9.1
Component: core Version:
Severity: medium Keywords: get_class
Cc: Language:
Patch status: Platform: all

Description (last modified by pmichaud) (diff)

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

Change History

Changed 5 years ago by pmichaud

  • summary changed from Various issues with get_class interface to [BUG] Various issues with get_class interface

Changed 5 years ago by pmichaud

  • priority changed from unknown to major

Changed 5 years ago by pmichaud

  • component changed from none to core

Changed 5 years ago by pmichaud

  • severity changed from none to medium

Changed 5 years ago by coke

  • summary changed from [BUG] Various issues with get_class interface to Various issues with get_class interface

Changed 5 years ago by pmichaud

  • description modified (diff)

Changed 5 years ago by whiteknight

  • status changed from new to assigned
  • platform set to all
  • keywords get_class added
  • milestone set to 0.9.1
  • owner set to whiteknight
  • type changed from bug to todo

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).

Changed 5 years ago by whiteknight

  • status changed from assigned to closed
  • resolution set to fixed

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.

Note: See TracTickets for help on using tickets.