Re: Re: Class/Object Method Lister

[stvn]

Markov,

I looked at your OODoc system. I like certain aspects of it, although the removal of documentation from the source was not one. Not that having documentation in source makes it any more likely that it will be read and/or updated, but having it all in one place tends to help. Maybe you should consider placing all you markup inside "=pod" and "=cut" directives or insisting the user places the documentation after the __DATA__ tag. Either one would allow you to keep your POD extensions intact.

But I do agree with you that POD is very limited/limiting. I myself have created an alternate POD. I call it XOD actually. I built it to be "extensible" POD, much like XML is to HTML, XOD is to POD. XOD of course isn't the best name for it (as the acronym doesn't work), but it is the name of the evil villian in the original Superman movie (although that was surely spelt with a Z).

XOD has only a few reserved "tags" which perform special functions in the parser. Things like including files and slurping verbatim text. Other than that its "tags" are up to you. It will parse into a tree-based structure, that can be transformed with a simple Visitor style object. Becuase of this, you can really do anything you want with it in terms of dialects (again, just like XML). It has 2 kinds of "tags". Containers, which start with a "=whatever" and always end with an "=end". And single elements, which are denoted by a colon at the end of the "tag" name, like this; "=element:". It also picks up lines of plain text, and processes embedded "<>" structures.

The best way to illustrate this all though, is an example. Here is a quick snippet of some XOD code:

=xod

=head1: Testing

Hello there B<World>, I<how are you B<?>>

=list
    =item: L<test>
    =item: other item
=end

=cut

And here is the tree structure that will convert to:

XOD::Command (head1:)
    XOD::Text (Testing)
XOD::Paragraph
    XOD::Text (Hello there )
    XOD::Modifier (B)
        XOD::Text (World)
    XOD::Text (, )
    XOD::Modifier (I)
        XOD::Text (how are you)
        XOD::Modifier (B)
            XOD::Text (?)
XOD::Command (list)
    XOD::Command (item:)
        XOD::Modifier (L)
            XOD::Text (test)
    XOD::Command (item:)
        XOD::Text (other item)

This isn't released yet (its part of a much larger framework I am developing at my company (up too 125 classes now and almost 14,000 lines of code). If you are interested in knowing more, msg me and we can talk.

-stvn

[markov]

I looked at your OODoc system. I like certain aspects of it, although the removal of documentation from the source was not one.

... then I have to create an option to leave the docs in. However, when real pod is created, you do not want the meta-pod in X.pm conflict with the produced pod in X.pod.

Besides, I heard too many people say that they do not want pod merged with the code because it would make compilation slower. Now those people have no reason not to write docs anymore.

My choice was for logical markup i.s.o. visual markup, for instance '=method' and '=option'. Does XOD do more than syntax parsing?

[stvn]

Markov,

Ahh, I see. I didn't realize that you tranformed the meta-pod into real pod. It makes much more sense now. Although I still think I would like my files to stay untouched, but I am an admitted paranoid. :)

Does XOD do more than syntax parsing?

No, at this point, XOD does no more than syntax parsing. But at this point, that is all it is supposed to do. It is by no means a doucmentation system on the level of OODoc. I have written 2 Visitor/Transformers one for "XOD to XML" and another for "XOD to HTML", and I am planning 2 more ("POD to XOD" and "XOD to POD" for backwards and forwards compatability). Primative for sure compared to what you have.

-stvn