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.
  • This is certainly an idea from Smalltalk that has been lost for the ages.

    As originally designed in Smalltalk, I think that the category descriptions for methods were done using metadata (comments):

    "methods for parsing"
    ....
    "methods for error handling"
    ....
    The code browser would respect these comments scattered about the code and use that information to simplify the display in the code browser.

    Putting this information into the op tree sorta sounds good, but modifying the syntax of the language (through a user-defined category block) feels like it's taking three steps towards Java just to get one step closer to Smalltalk.

    How does this look:

    use Categories;        ## load behaviors to respect '=category' comments
    class SomeClass {

    =category factoryMethod
      method new {...}

    =category accessor
      method attrib {...}

    =category setter
      method set_attrib {...}

    =category strangeCategory
      method foo {...}
      method bar {...}
    }
    (To be fair, that code is much smaller because the Categories module isn't stubbed in.)

    Personally, I like this better because the metadata for this module is metadata. Presumably the code browser is going to have access to raw source code, and can annotate it's view of the world accordingly. That also means that the optree doesn't need to be decorated during execution, when this information is likely to be meaningless.

    Depending on how the parser finally winds up, the Categories module could be quite small -- equating the =categories tag to a self-contained =for statement that doesn't need an empty paragraph to be terminated. The code browser could switch in a different Categories module that actually processes the metadata and annotates the sub definitions. Or perhaps that trivial amount of code is always switched on, but never used outside the code browser...

    • The catch with that approach is that the putative browser has to start parsing the source file to work out what's going on.

      If category information is just another attribute on the coderef then the browser doesn't have to start looking in the source to build its browsable structure, it only has to worry about it when you want the method listing.

      Of course, if B::Deparse's perl6 equivalent can be relied on to work in all cases, you don't even need to see the source, it can be regenerated from what's in memo
      • The catch with that approach is that the putative browser has to start parsing the source file to work out what's going on.

        ....then that's a good argument to adopt macros or otherwise tweak the parser to take a =category comment as a way of specifying a category attribute on a sub.

        The category {...} syntax you propose looks like it's adding another level of lexical scope, when all it's doing is adding metadata. That sounds like an impedence mismatch to me.

        I'm less concerned about how the internals

        • The 'new scope thing' is a very good point; most of the time you really don't want to do that. And I don't want to have to think about

          class foo {
            ...
           
            my category private is private {
              sub foo {...}
              sub bar {...}
            }
          }

          I am convinced. I'm not sure I like your proposed syntax though.

          However, quibbling over syntax is beside the point. The point is that Perl6 is going to make it possible for us to do this sort of categorization.

    • Few things Parrot's doing structurally that may help:
      1. Docstrings as a guaranteed propery on everything. (Potentially empty mind, but guaranteed)
      2. Ties between the bytecode stream and the AST
      3. Ties between the bytecode stream/AST and the original source

      So while there's no guarantee that everything'll be there (someone might strip the bytecode) you should be able to look at a sub ref, grab a pointer to its AST, grab a pointer to the beginning of its source, and potentially see any documentation that's been