Best Practices for creating an OO version of an existing CPAN module?

topher has asked for the wisdom of the Perl Monks concerning the following question:

I'm looking for suggestions or thoughts on the best way of handling this, as it isn't something I've personally run into, and I haven't been able to find much regarding it.

I've come across a module in CPAN that I really like, however it's written in as a very procedural module, even though it seems like a great candidate for OO to me. Additionally, it would integrate much cleaner into some other stuff I'm doing if it were an OO module.

I'm willing to do the work to write an OO version of the module. My question is, what is the best way to go about this? Specifically, I'd love to hear thoughts and suggestions on:

Should I contact the author of the existing module and try to get the OO interface integrated into the existing package?
Is it better to just create a totally separate module? Looking at the code for the existing module, it may be difficult to implement it as a wrapper around the existing module, so it would possibly entail duplicating the functionality, and tracking any enhancements or changes made between the two.
If the best solution is a separate module, what is the best way to name it? Match the existing module and add an OO suffix (Foo::Bar::OO or Foo::BarOO)? Or something else?

Any other suggestions, thoughts, or tips would be great appreciated.

Comment on Best Practices for creating an OO version of an existing CPAN module?

Replies are listed 'Best First'.
Re: Best Practices for creating an OO version of an existing CPAN module? by tmharish (Friar) on Feb 25, 2013 at 05:55 UTC
Should I contact the author of the existing module and try to get the OO interface integrated into the existing package? IMHO Thats the best option. I would get in touch with the author and provide the integration. If the author does not respond or/and the module has not been maintained in a while you can always ask to take over the maintenance of the module. Also when providing the options for OO you might want to ensure backward compatibility.	[reply]
Re^2: Best Practices for creating an OO version of an existing CPAN module? by topher (Scribe) on Feb 25, 2013 at 21:31 UTC
The module isn't very old old, and the author seems active, so I don't think there will be any issues with getting in touch with him. Trying to maintain maximum compatibility with the existing module will absolutely be a high priority if I OO-ify it. The more similar it is, the easier it will be to maintain and use. Just to clarify, you believe the best option is to integrate the OO interface into the same module as the procedural interface, and not to put it in a separate package? Any particular reason or advantage for this, or just personal preference? Note: I'm not disagreeing with you, just trying to clarify my understanding of the best way forward.	[reply]
Re: Best Practices for creating an OO version of an existing CPAN module? by vinoth.ree (Monsignor) on Feb 25, 2013 at 05:48 UTC
*Should I contact the author of the existing module and try to get the OO interface integrated into the existing package?* Better check with the author first, after that you can decide on implementing the separate module.	[reply]
Re^2: Best Practices for creating an OO version of an existing CPAN module? by topher (Scribe) on Feb 25, 2013 at 17:33 UTC
So you are of the opinion that the best option is to try to include both interfaces in the same module? Note: I'm not disagreeing with you, just trying to make sure I understand. I've seen a couple of modules that supply both a procedural and OO interface in the same module, and a bunch that implement them separately. I'm trying to figure out if there's any benefit or detriment to one over the other.	[reply]
Re: Best Practices for creating an OO version of an existing CPAN module? by BrowserUk (Patriarch) on Feb 25, 2013 at 18:20 UTC
The first thing I'd ask myself is: if the module functions okay using a procedural interface; what benefit does putting an OO wrapper around it bring? With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^2: Best Practices for creating an OO version of an existing CPAN module? by topher (Scribe) on Feb 25, 2013 at 20:25 UTC
This biggest issue comes from the use of package variables to maintain state. I have a need for the equivalent of multiple instances, and I'd rather not have to write wrapper code to continually update the package state variables every time I call a module function. An OO interface where I could more cleanly have multiple instances, each with it's own object state, seems like the best solution.	[reply]
Re^3: Best Practices for creating an OO version of an existing CPAN module? by BrowserUk (Patriarch) on Feb 25, 2013 at 20:30 UTC
This biggest issue comes from the use of package variables to maintain state. What module are we talking about here? With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^4: Best Practices for creating an OO version of an existing CPAN module? by topher (Scribe) on Feb 25, 2013 at 20:42 UTC
Re^5: Best Practices for creating an OO version of an existing CPAN module? by BrowserUk (Patriarch) on Feb 25, 2013 at 22:01 UTC
Some notes below your chosen depth have not been shown here
Re^3: Best Practices for creating an OO version of an existing CPAN module? by blue_cowdawg (Monsignor) on Feb 25, 2013 at 20:51 UTC
This biggest issue comes from the use of package variables to maintain state. I have a need for the equivalent of multiple instances, and I'd rather not have to write wrapper code to continually update the package state variables every time I call a module function. Eh? What package are we talking about here and what package variables? Peter L. Berghold -- Unix Professional Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg	[reply]
Re^4: Best Practices for creating an OO version of an existing CPAN module? by topher (Scribe) on Feb 25, 2013 at 21:22 UTC
Re: Best Practices for creating an OO version of an existing CPAN module? by blue_cowdawg (Monsignor) on Feb 25, 2013 at 18:37 UTC
've come across a module in CPAN that I really like, however it's written in as a very procedural module, even though it seems like a great candidate for OO to me. Additionally, it would integrate much cleaner into some other stuff I'm doing if it were an OO module. As BrowserUK pointed out is I'd be doing a consideration of the benefit of going OO with the module. Secondly I'd definitely contact the current maintainer if there is one to determine their interest first. Even though the majority of modules I write are OO in nature I'm not always 100% convinced that's the way to go every time. Peter L. Berghold -- Unix Professional Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg	[reply]
Re^2: Best Practices for creating an OO version of an existing CPAN module? by topher (Scribe) on Feb 25, 2013 at 20:33 UTC
I've definitely considered that. While most of the modules I personally write tend to be OO these days, I have no problem at all using non-OO modules as long as it doesn't present limitations. I'm a huge fan of lazy coding and using someone else's code any chance I can (much love to CPAN), so I generally don't jump in to rewrite an existing module if I don't feel it's needed. In this case, as I mention in my reply to BrowserUK, the need for multiple "instances" and the use of package state variables is causing me some issues that an OO version of the module would seem to cleanly solve.	[reply]

Back to Seekers of Perl Wisdom