newbie01 perl <newbie01.p...@gmail.com> asked:
> Am wanting to change my Perl scripts to get it to run on several UNIX
> flavours and Windows. At the moment, the only way I can think of how to
> accomplish that is always having the following checks on each and every
> sub that I have.
>
> Can anyone please suggest if there is a better way of doing this
> besides what am doing now? Am not sure whether creating a module
> for each OS to use is the solution although I don't know how to create
> a module anyway. I found one tutorial and get lost somewhere along the
> way on how to create a module ... :-)
>
>
> if ($^O eq 'MSWin32') {
> system "dir $ARGV[0]";
> }
Either this is a bad example or you're doing something wrong - listing a
directory works well using the opendir()/readdir() commands in conjunction with
the File::Spec::* family of modules for parsing and constructing path names.
It's probably much less of a PITA to work with, too, since you don't have to
parse 17 different output formats.
For other stuff, you should leverage the power of CPAN - search.cpan.org is
your friend. For disk space usage for example, you might be able to use
http://search.cpan.org/~iguthrie/Filesys-DfPortable-0.85/DfPortable.pm
As for creating your own modules, have you tried "perldoc perlboot"?
The absolute minimum to make and use your own modules goes something like this:
Decide where you want to keep your modules. For small projects I prefer to keep
them in a directory called "lib" in the same directory as my Perl scripts. Perl
needs to be told about that path, so I use the following code snippet in the
header of my scripts:
use File::Spec::Functions qw( catpath splitpath rel2abs );
use lib catpath( ( splitpath( rel2abs $0 ) )[ 0, 1 ], 'lib' );
This tells perl to look first in my local lib directory that's in the same
directory as the script (wherever that is).
Decide on your module namespace and the module name. Of course you're free to
name your modules whatever you like, but the smart way is to create a hierarchy
of names that identifies the module and its purpose, and add your company name
or another unique identifier at the top level. So if you work for Quux, Inc.
and you're writing a module that implements the Froob network protocol, you
might want to name the module Quux::Net::Froob.
Note that the module name that you're going to "use;" must be reflected in the
file's path name. So if you decide to keep your Quux::Net::Froob module in the
subdirectory lib, it's relative path name would be lib/Quux/Net/Froob.pm.
Please note that casing and spelling must be identical between module name and
file path.
As to the contents of the module, a good starting point might be:
package Quux::Net::Froob;
use strict;
use warnings;
sub new {
my $class = shift; # 1st argument is class name
my $self = { }; # use empty anon hash to store instance
variables
bless($self, $class); # bless the hash ref into an object
return $self;
}
sub set {
my($self, $data) = @_;
$self->{'data'} = $data;
}
sub get {
my($self) = shift;
return $self->{'data'};
}
1;
__END__
The "1;" at the end of the module code is recommended since the module won't
load if it's code doesn't evaluate to a true value during import.
To test your own module, try
#!/usr/bin/perl -wl
use strict;
use File::Spec::Functions qw( catpath splitpath rel2abs );
use lib catpath( ( splitpath( rel2abs $0 ) )[ 0, 1 ], 'lib' );
use Quux::Net::Froob;
my $foo = new Quux::Net::Froob;
$foo->set('blarg.');
print $foo->get();
__END__
If you're looking for a good book on Perl OO programming, I can personally
recommend "Object oriented Perl" by Damian Conway
(http://books.perl.org/book/171).
Hope this helps to get you started,
Thomas
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
