Creating Perl Modules and OO Programming


http://www.tutorialspoint.com/perl/perl_object_oriented.htm


http://www.perlmonks.org/?node_id=586646
Defining classes and inheritance using packages within a single .pl file, without creating modules

http://stackoverflow.com/questions/2621225/how-can-i-call-a-perl-package-i-define-in-the-same-file

http://oreilly.com/catalog/prkunix/excerpt/PWPMch01.html#MARKER-9-23

http://stackoverflow.com/questions/1748896/in-perl-how-do-i-put-multiple-packages-in-a-single-pm-file

http://stackoverflow.com/questions/1143874/what-is-the-difference-between-package-module-and-class-in-object-oriented-perl

http://broadcast.oreilly.com/2008/11/beginners-introduction-to-obje.html

http://perldoc.perl.org/perlobj.html

http://www.perl.com/doc/FMTEYEWTK/perltoot.html

http://turtle.ee.ncku.edu.tw/docs/perl/manual/pod/perltoot.html

http://www.perl.com/pub/2002/05/14/mod_perl.html



Excerpts below from an old article, located at:
http://mathforum.org/ken/perl_modules.html

Related: 

* http://perldoc.perl.org/perlobj.html
* http://broadcast.oreilly.com/2008/11/beginners-introduction-to-obje.html


Object Oriented Perl syntax 

code.
package NewModule;

use strict;
use vars qw($VERSION);
$VERSION = '0.01';

sub new {
  my $package = shift;
  return bless({}, $package);
}

sub verbose {
  my $self = shift;
  if (@_) {
    $self->{'verbose'} = shift;
  }
  return $self->{'verbose'};
}

sub hoot {
  my $self = shift;
  return "Don't pollute!" if $self->{'verbose'};
  return;
}

1;
__END__
code..


br. Test code

code.
# Before `make install' is performed this script should be runnable with
# `make test'. After `make install' it should work as `perl test.pl'

######################### We start with some black magic to print on failure.

# Change 1..1 below to 1..last_test_to_print .
# (It may become useful if the test is moved to ./t subdirectory.)

BEGIN { $| = 1; print "1..1\n"; }
END {print "not ok 1\n" unless $loaded;}
use NewModule;
$loaded = 1;
print "ok 1\n";

######################### End of black magic.

# Insert your test code below (better if it prints "ok 13"
# (correspondingly "not ok 13") depending on the success of chunk 13
# of the test code):

# Test 2:
my $obj = new NewModule;
$obj->verbose(1);
my $result = $obj->hoot;
print ($result eq "Don't pollute!" ? "ok 2\n" : "not ok 2\n");

# Test 3:
$obj->verbose(0);
my $result = $obj->hoot;
print ($result eq "" ? "ok 3\n" : "not ok 3\n");
code..


h2. Inside-out objects

inside out

[[Perl example of inside-out object]]

[[Perl example of inside-out object number 2]]

http://perltraining.com.au/tips/2006-03-31.html

http://perldoc.perl.org/perlobj.html#Inside-Out-objects

http://perldoc.perl.org/Hash/Util/FieldHash.html

http://search.cpan.org/dist/Object-InsideOut/lib/Object/InsideOut.pod


h2. getters and setters



http://stackoverflow.com/questions/1390082/in-perl-are-there-disadvantages-to-generating-getters-and-setters-rather-than-ha


http://etutorials.org/Programming/Perl+objects,+references+and+modules/Chapter+11.+Some+Advanced+Object+Topics/11.5+Creating+Getters+and+Setters+More+Easily/

http://search.cpan.org/~dconway/Class-Std-0.011/lib/Class/Std.pm

http://perldoc.perl.org/perlootut.html



!!!! http://www.perlmonks.org/?node_id=317885

q.
_So, the solution to this is accessing data or setting it via methods . . . I've seen a getter/setter in OO tutorials, one written for each attribute._

Yes, most tutorials do it that way. They're wrong, or at least misleading. Getter/setter methods (or for those who like fancier words, accessors/mutators) should be avoided. Sometimes you do need them on a few attributes, but if your design calls for accessors/mutators on every internal attribute, you need to rethink your design. Doing it that way won't really result in an object, but a datastructure that happens to be accessed with an object-like syntax. The only difference between this:

code.$obj->{field}
code..

And this:

code.$obj->field();
code..

Is some fancy syntax. I bet the second form is slower, too (haven't benchmarked it, though).

Now when you actually do need accessors/mutators . . .

_Why do you need a different method for each bit of data?_

True to TIMTOWTDI, Perl offers many ways of producing accessors/mutators. Your way isn't necessarily wrong. If use strict 'subs'; was useful for method lookups, then I think you can make a stronger argument against what you're doing (since a method-per-attribute way would give you compile-time errors when you make a typo). Since methods are all looked up at run time, use strict 'subs'; isn't particularly useful no matter how you do it.

One problem with your way of generating accessors/mutators is that, unless you do checking inside the method, a user can insert an attribute that didn't previously exist.

There are other ways of generating accessors/mutators. One is to use AUTOLOAD, but it's slow. Class::Accessors works by using closures, like this:

code.my @FIELDS = qw( a b c d );  # Put your field names here
foreach my $field (@FIELDS) {
    no strict 'refs';
    *$field = sub {
        my $self = shift;
        $self->{$field} = shift if @_;
        return $self->{$field};
    };
}
code..

The symbol table will make a reference to the same subroutine each time, thus saving memory. It's also as fast as any other method lookup. If you wrap the above in a BEGIN block, there will be no runtime hit for generating the methods
q..

#perl
#programming
#objectoriented