This may sound rude -- but write the module for yourself. Don't try to second guess how other people are going to want to use it. If you make it, and release it, and other people have suggestions, they'll tell you.
If you make it complicated to the point where you don't even want to use the module, you've done too much work. You know what works for you. Without some sort of focus group, you're not going to know what it is that everyone else wants ... so put out something that helps you, and then see what other people comment on that would help them.
The most important thing to writing modules is writing documentation, which I find to be one of the more difficult parts of the experience. So I would suggest writing the documentation first. (yes, I know, it sounds stupid, but it's actually like writing a use case, or writing test cases first).
You write the documentation in a way that it makes the module easy to use in a program, then write the module to fit that documentation. If you have to, you can also write a cookbook as a series of ways that you expect the program to behave, and then use it as both documentation, and tests
In reply to Re: Writing TIMTOWDI-friendly CPAN Modules
by jhourcle
in thread Writing TIMTOWDI-friendly CPAN Modules
by eibwen
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |