Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

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

by topher (Scribe)
on Feb 25, 2013 at 05:38 UTC ( #1020460=perlquestion: print w/ replies, xml ) Need Help??
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?
Re: Best Practices for creating an OO version of an existing CPAN module?
by vinoth.ree (Parson) 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.

      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.

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.

      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.

Re: Best Practices for creating an OO version of an existing CPAN module?
by BrowserUk (Pope) 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.

      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.

        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.
            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
Re: Best Practices for creating an OO version of an existing CPAN module?
by blue_cowdawg (Prior) 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

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1020460]
Approved by vinoth.ree
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (12)
As of 2014-07-23 08:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (137 votes), past polls