The 2nd thing you should do is add comprehensive tests, testing EVERYTHING. See Tie::PureDB for an example on how to structure that.

The 3rd thing you should do is use vars instead of our, and remove use warnings;, that way your module works with older perls, but that's entirely up to you (some people are forced to use old perls, so if they wanna user your module, they'll have to make the adjustments themselves).

You might wanna consider inling your pod (=head2 function name ... =cut sub function ...), or even separating the pod into a separate document (ANSIMenu.pod), but that's also a preference thing (if you search for for inline pod you'll find some discussion of this).

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests. ** The Third rule of perl club is a statement of fact: pod is sexy.

Hi PodMaster

I have improved the pod and added some 76 tests. Everything that is not interactive and does not print to STDOUT directly is tested now. Thanks for the nudge in the right direction. The new version is available here

I had to change the destructor though. It cleared the screen which is annoying during/after the tests, so I made it optional. Well, more freedom to the user is always a good thing anyway...

There's one problem left (I think). The constructor does clear the screen too and I am reluctant to make that optional as I have no reliable way of getting the current position of the cursor (anyone know of something?), but it seems i'll have to. The test suite calls new() and thus clears the screen, which is not a good thing there. I need to think on a robust way of doing this...

Thanks for your comments

I know about the long lines. They come from an example that demonstrates automatic clipping if the line length exceeds the terminal width. As you can see from the rest of the pod I did try use propper line lengths. I'll probably have to adjust the "bad" lines considering your comment.

I am a bit reluctant to remove use warnings, but I suppose I could use it while writing the code and comment it just before building the distribution. However to be honest I don't know if the module would work with older perls at all. As far as I can see it should work with 5 and up, but I am not sure about that. Can you tell me which version introduced "use warnings" as a better "-w"?

I only use "our" for the definition of $VERSION. I thought it was appropriate for that. Am I mistaken? Everything else should be strictly private to the package itself.

About the pod. What's the consensus around here? I am used to writing it after _END_ mostly because I feel it makes the code less cluttered. I always try to write the code itself as clear as possible, even at the cost of some performance, because most of the time others have to use it after I've written it and they might not be equally at home with Perl as me or the people frequenting this site. I don't have a problem with putting the attribute and method related parts next to the pieces of code they relate to. But this way it is all bundled together. To the users it shouldn't matter anyway as they'll probably only read it through pod2xxx or perldoc.

I would like to test everything, but I just can't think of ways to test the menu's functionality. How do you verify a terminal supports ANSI sequences? Or really does return the keycodes I am using? I could use some hints on this one...

Thanks for your comments. I am off now to start reading the page behind the link to Tie::PureDB now.

Cheers - L~R

I did just before posting, but somehow it was posted as coming from "Anonymous Monk". Probably had to do with me not accepting cookies. I changed that for this site now. So this should come through as being from "jadev".