Mixing OO & non OO code in a module

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

Greetings fellow monks, a stylsitic question here

I've written a module which simplifies access to a recon database for an RPG. The info in this database is a list of city blocks with some additional info for each. This module is also intended to be used by any number of perl scripts.

So, what I have for it to be generic is 1 object constructor and a few subroutines which run as methods of that object, so that each city block is represented by an object. Plus 1 other sub that is needed but it does not make sense to call with a block object (it works out what map coords you want to look at).

Is there a better/more elegant way of doing this? So far I've only really used objects as complex data stores (like a c struct) or if you'd normally be passing several of them around.

just another cpan module author

Comment on Mixing OO & non OO code in a module

Replies are listed 'Best First'.
Re: Mixing OO & non OO code in a module by hv (Prior) on Jun 06, 2006 at 12:44 UTC
I'd normally make such things class methods - if I don't, I find I'm always forgetting to type `My::Class::function(...)` instead of `My::Class->function(...)`, and it becomes a lot more convenient if I have the classname in a variable: `my $class = "My::Class"; my @coords = $class->look_at(something);` [download] Hugo	[reply] [d/l] [select]
Re^2: Mixing OO & non OO code in a module by jdhedden (Deacon) on Jun 06, 2006 at 16:25 UTC
If your class doesn't get inherited, you can do it both ways using: `sub function { # Allow calling as a subroutine or class method shift if ($_[0] eq __PACKAGE__); ... }` [download] If you're doing inheritance, you'd need something more involved, but you get the idea. Remember: There's always one more bug.	[reply] [d/l]
Re: Mixing OO & non OO code in a module by MonkE (Hermit) on Jun 06, 2006 at 12:52 UTC
When doing object-oriented programming, the first thing you should do is make a list of all of the types of objects that you have (or would like to have) in your finished program. Write down their methods and functions too. Arrange them and rearrange them while they are still just names on a piece of paper. It's well worth an hour of your time to come up with a conceptually sound set of object (classes) before you start coding. Another thing to remember about object-oriented programming is that there is no single "right" answer. Lots of different object models could solve your problem. And bear in mind that not everything needs to be an object (or an object's method). In this particular case though, I think you said it yourself: "it does not make sense to call with a block object." That strongly suggests to me that it probably doesn't belong as part of a "block" object. Perhaps it should be part of a different kind of object (such as "map" for example).	[reply]