I'm glad you like it!
I am, however, curious to know why you want to support more than one method (3!) to interact with your module.
The TL;DR is that I know people have different preferences, and since all three interfaces are fully tested and provide the same functionality (same parameters, same safety features, etc.), it really just is a matter of preference. The slightly longer answer is:
- I started with only the "single magic tied filehandle" interface because I thought it was kind of neat, and it helps keep short scripts short. However, I realized that not everyone likes too much magic, plus it might be too hard to remember which I/O functions operate on the input file and which on the output file, so
- I implemented the "two filehandles" interface because I thought it would be the most natural, and indeed, as I demonstrated in the root node, for code that is already using two filehandles, no major changes to the I/O code should be needed.
- By that point however, I was packing too much into one module and I was running into implementation problems, so I made the cleaner separation of putting the core functionality in an OO module, and wrapping that functionality with the tied filehandles. I figured that some people might prefer OO and/or dislike tied filehandles. It has the added benefit of being the only of the three interfaces that doesn't use tied filehandles at all, in case the user wants to do something fancy with the underlying filehandles, like tie-ing them on their own.