Re^2: Best Practices for creating an OO version of an existing CPAN module?

Replies are listed 'Best First'.
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
I've been avoiding naming it because I'm really interested more in high level thoughts about process, procedure, and best practices around recreating an existing CPAN module with an OO interface, as opposed to the details of the module itself. I'd really like to hear more thoughts and recommendations on how to handle this in the general sense. Is it best to combine the procedural and OO interface into a single package? Or have them in separate packages? Why is one better? Or is there no real consensus on this, and no real advantage or disadvantage to either method? However, for the sake of completeness, the module is Net::Statsd. It uses a pair of package variables to set the destination host/port, and I have a need to for multiple separate destinations.	[reply]
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
the module is Net::Statsd. It uses a pair of package variables to set the destination host/port, and I have a need to for multiple separate destinations. For that particular module, I agree an OO interface would seem like the best way to go. As for how. The existing interface does not lend itself to being objectised without effectively re-writing the interface of every procedure. As such, I think you'd be better off using a completely separate package (say Net::Statsd::OO or similar) and just writing it from scratch. With reference to the existing; but without having it as a dependency. 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^6: Best Practices for creating an OO version of an existing CPAN module? by topher (Scribe) on Feb 28, 2013 at 05:52 UTC
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
Discussed in Re^4: Best Practices for creating an OO version of an existing CPAN module?.	[reply]


There's more than one way to do things
	PerlMonks