Perl module class method vs ordinary subroutine - perl

Question

So I was wondering if there is any difference in usage between a Perl class method and an ordinary subroutine from a standard module. Is there a time you would use one over the other? For this example, I'm assuming that no object methods are present in either module.
Quick little main class here:
#!/usr/local/bin/perl
use strict;
use warnings;
use Foo;
use Bar;
my $arg1 = "blah";
my ($str1, $str2);
$str1 = Foo::subroutine($arg1);
$str2 = Bar->subroutine($arg1);
exit(0);
Package Foo would hold my ordinary subroutine call
use strict;
use warnings;
package Foo;
sub subroutine {
my $arg = shift;
my $string = "Ordinary subroutine arg is $arg\n";
return $string;
}
1;
Package Bar would hold my class method call
use strict;
use warnings;
package Bar;
sub subroutine {
my $class = shift;
my $arg = shift;
my $string = "Class method arg is $arg\n";
return $string;
}
1;
Normally if I'm writing Perl code, I would just use the class method option (like with the Bar example), but I started pondering this question after reading some code from a former coworker that used the syntax like in the Foo example. Both seem to do the same thing inherently, but there seems to be more than meets the eye.

Answer 1

The decider is whether your Module is an object-oriented module or not.
If Module is simply a container for a collection of subroutines, then I would expect it to use Exporter and offer the opportunity to import a subset of its subroutines into the calling name space. An example is List::Util
On the other hand, if there is a constructor Module::new, and the intention is to use it in an OO manner, then you shouldn't mix simple subroutines in with methods (except perhaps for private subroutines that the module uses internally). An example is LWP::UserAgent
So I would expect the sources to be written like one or the other of these, and not a mixture in between. Of course there are always circumstances where a rule of thumb should be ignored, but nothing comes to mind in this case.
Foo.pm
use strict;
use warnings;
package Foo;
use Exporter 'import';
our #EXPORT_OK = qw/ subroutine /;
sub subroutine {
my ($arg) = #_;
"Ordinary subroutine arg is $arg\n";
}
1;
Bar.pm
use strict;
use warnings;
package Bar;
sub new {
my $class = shift;
bless {}, $class;
}
sub subroutine {
my $class = shift;
my ($arg) = #_;
"Class method arg is $arg\n";
}
1;
main.pl
#!/usr/local/bin/perl
use strict;
use warnings;
use Foo 'subroutine';
use Bar;
my $arg1 = "blah";
print subroutine($arg1);
print Bar->subroutine($arg1);
output
Ordinary subroutine arg is blah
Class method arg is blah

Answer 2

There's nothing inherently wrong with an ordinary subroutine. They do what they're designed to do very well.
Methods on the other hand, do all the same things and play nicely with any Class that inherits from yours.
So ask yourself:
Are you expecting/permitting/encouraging folks to write Classes that inherit from your module?
Is your module defining a more complex data structure that works well as an object?
or
Is your module a library of utilities that operate on fundamental data types?
There's plenty of room in this world for both, but if you find yourself, as you did in Bar, ignoring $class (or more commonly $self) throughout the module, then perhaps you've gone too far by designing them as methods. More importantly, anyone who tries to inherit from your marginally OO "Class" will get a rude surprise when your methods can't tell the difference between the two classes...

Answer 3

This is more a question of code paradigm.
There is absolutely nothing wrong with a non object oriented approach to your code. It works, and it works well.
However, object orientation provides a bunch of benefits that are worth considering - and if they're something you want, go an OO route.
Specifically - objects provide encapsulation. It makes it a lot easier for me to write a module and you to just use it. Look at say, LWP::UserAgent for an example:
require LWP::UserAgent;
my $ua = LWP::UserAgent->new;
$ua->timeout(10);
$ua->env_proxy;
$ua->agent('Mozilla/5.0');
my $response = $ua->get('http://search.cpan.org/');
if ($response->is_success) {
print $response->decoded_content; # or whatever
}
else {
die $response->status_line;
}
Now, all of the above you could do via inherited subroutines. But if you wanted to do multiple fetches of multiple pages, you'd either have to:
Build a sub that took all the parameters you needed - including returning somehow, a 'success/fail/result' - maybe in an array?
Otherwise have 'state' hidden in your external module.
OO is just a neater, more understandable method of doing that. (There are other benefits of doing OO, which I'm sure you could Google).