Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • According to that diagram, ::Point is not a ::Class. Can that be right?
    • A Point is-a Object... That is, ::Point inherits from its superclass, ::Object, as shown by the white pizza-arrow line. Surely a Point object would not be a valid class object.

      On the other hand, the metaclass object ::Point itself -- on the left-hand side -- is an instance of ::Class, as shown by the dotted line.

      • I think I see what you mean but I don't like the class/metaclass distinction at all. I'm in favour of pulling everything out into the runtime side of the drawing. That is, I think ::Point and ::Point.meta should be the same, and ::Point is not just a metaclass object but an honest-to-goodness class object. Why the distinction?
        • The idea is the left-hand-side MetaClass should not be distinguishable, by the user, from the right-hand-side ::Class.

          Conceptually, if we are implementing perl6 on perl6, then sure ::Class is just the metaclass itself.

          But if you are, say, implementing perl6 on perl5 (which is what we're doing now), then you need a perl5-side entity to represent a perl6 class. That's what the MetaClass is.

          Otherwise, you can't communicate with other perl5 objects -- "native" ones like DBI.

          But it is that exact entity that gets exposed as a ::Class object, so the user won't be able to tell the difference.