|more useful options|
I see that. And, I did not intend my comment to be in any way critical of, nor disrespectful of, you or your work.
Indeed, it is highly desirable to have modules that make it easier (and more trouble-free) to “DDRT=Do The Right Thing.” The natural and understood trade-off is, the need to understand precisely what they are doing ... and the need to improve-upon the “DDRT” module without breaking a mountain of existing code that has been written to use it. Every ointment has its houseflies...
The bugaboo is this: if we have n Perl modules that are all relying upon the behavior of (some hypothetical) DDRT 1.0, those n modules now have a material dependency ... not just to DDRT 1.0, but to one another. Not only might you find it to be difficult to change or to replace the DDRT module, but also you might find it problematic to “do anything different” in any one of the client modules. It might be “all, or nothing.”
If we found it business-necessary to implement “different” behavior in some particular module, we might find that we have no practical choice but to replace the DDRT module calls with “what that module would have done, only slightly different.” And, when that continues to happen over time, the benefits begin to disappear, or are negated.
Alternatively, some clever programmer might find a way to “work around” the not-quite-desired behavior or implementation of DDRT through resorting to some kind of “clever trick.” Something that leverages a side-effect, or an undocumented subroutine, or something even more obscure. “It works!” But... how soon will it be forgotten? And, when we replace DDRT with NAIDDRT (“New And Improved...”), suddenly there are problems. Maybe the problems spew all over our production-schedule, but maybe ... far worse ... they don’t. Or, they initially do not appear to. It is three o’clock in the morning. Your beeper just went off ...
Houseflies do not go to sleep at night.
Again, I do not intend anything negative by these observations.