|Perl Monk, Perl Meditation|
Thanks for the replies, guys. Apologies about the lack of code provided BrowserUk, I definitely put too much emphasis on "convert my code" when what I really want is "how do you guys implement this in your own modules?".
Before going any further, I do understand the mechanics behind Perl OO - blessed hashref, etc. Thank you for reiterating them for me =)
My main reason for wanting to implement this is that I have to work with these modules, which are essentially libraries of functions. In some calling scripts all you want is some subroutine out of the module. I don't want to mess with all that OO stuff - quick, lightweight, simple and easy with Exporter.
On the other hand sometimes (increasingly so, for me) I'll want something with a little more permanence and I think that some of my modules are "growing" in this direction. I want to create several module objects which have individually loaded configs either from the constructor call or loading config files. Then working with the libraries within these modules is simpler than having to pass all my configuration options to an exported function or having to reload configurations for the module.
If your procedural functions were written (or could be easily modified) to take a hashref containing the data they operate on, then making the module "OO" could be as simple as adding a constructor sub that builds a hash from its inputs, blesses a reference to it and returns it.
I only pass a hashref in this manner for functions that require more than 3 arguments. So I'm partially in that boat. I think this is what I meant by converting my functions to create a temporary object each time a function is called.
Having both is often no more than paying lip service to peoples wont to have things work in one particular way.
Am I wrong to want to do this? I like making everyone who's using my module happy. I like the flexibility.
Anyway, I am getting a very "look at your module usage and make up your mind one way or the other" vibe from you guys on this one. I'm a little surprised since so many CPAN modules support both pragmas.
I thought there might be a best practice style of going about this. Could be that the best practice style is decide which pragma is more important, write the module to support that, and then cobble the other pragma in as needed.
Strange things are afoot at the Circle-K.