paperlined.org
dev > perl > contribute
document updated 12 years ago, on Jul 15, 2011
========================
======== NAMING ========
========================

I really don't think that "Keyword::" is the best prefix for these modules.  The thing that
differentiates these modules from other similar modules:
    
    http://paperlined.org/dev/language_wonk/in_perl/extending_the_syntax.html

Is that it operates at the lexer level.

    (is that right?  Devel::Declare has an API that's surprisingly similar to this one...  I thought
    that Devel::Declare COULDN'T operate at the lexer level, but maybe I'm wrong about that?)


Anyway, if that IS the main distinction, then it really should be called something like
B::Lexer::* or something like that.
    




========================
======== PHASE1 ========
========================

        [Phase1 complete:   http://annocpan.org/~RGE/Keyword-API-0.0004/lib/Keyword/API.pm ]

Documentation enhancements:

    - For install_keyword(), note that only ONE keyword for the ENTIRE perl is supported right now.
      Only the most recent install_keyword() call is in effect.  All previous calls to it are
      discarded.  This is true even if two different packages try to use Keyword::API.
      (this may be improved upon in the future)

    - in the documentation for lex_read_to_ws(), rename "lex_read_token" to "lex_read_to_ws" in the
      example code          (this seems to be a simple documentation error)

    - explain that 'parser()' is a callback function within the package...  the sub name is hard-coded

            - it takes no arguments

            - currently, there's no way to find out what keyword triggered this call
                        (especially since only one keyword is supported at the moment)

            - when the function starts, the lexer buffer is at the first non-space following the
              keyword;  the keyword has already been consumed
    


========================
======== PHASE2 ========
========================

Code enhancements:

    - figure out how to have it support multiple keywords

    - when parser() gets called, pass it the keyword that triggered it



========================
======== PHASE3 ========
========================


Communicate to/with the developer:


    - request that the mixed spaces/tabs problem be fixed   (I won't do this myself -- I want the
      diff to be as minimal as possible, to make it very easy to understand)


TODO / possible code enhancements:


    - figure out how text encoding affects this....  the manpage specifically says "bytes", not
      "characters"...     so are