What is the difference between package, module and class in object oriented Perl?
Modules are a single file, a .pm file that provides code. That could be no packages, a single package, or more than one package. A module doesn't really care what is in it, so it can be code that inserts itself into the same namespace, a more-traditional set of subroutines in a library or define Perl's idea of a class.
A package, also known as a namespace, contains its own variables and subroutines. It's a way of segregating different parts of your program. You create the package and put your code into it:
package SomePackage;
sub some_subroutine { ... } # really SomePackage::some_subroutine
You load the module to get access to the package:
use SomePackage; # read and compile the module file
SomePackage::some_subroutine( ... );
A Perl class is a package and its associated behavior. The methods in a class are just normal subroutines, although when we treat the subroutines as methods, the first parameter is the thing (a package name or object, also known as the referent) that called method:
package SomeClass;
sub class_method { my( $class, #args ) = #_; ... }
sub instance_method { my( $self, #args ) = #_; ... }
Since the class is just a package like any other package and probably lives in a module, you access it the same way with use:
use SomeClass;
my $i = SomeClass->class_method( ... );
The OO arrow syntax does some special stuff to let the some_method subroutine know that it's being called as a method. Perl puts the referent (the SomeClass in this case) as the first argument. Additionally, when using the OO syntax, Perl knows to use its inheritance features.
Methods called with '->' get the referent as the first parameter to the method, so this call:
SomeClass->new('world');
is syntactically the same as if you had called it with the class name as the first parameter:
SomeClass::new( 'SomeClass' ,'world'); # no inheritance this way
That works the same for objects too. When an object is the referent:
my $i = SomeClass->new();
$i->bar( 'world');
the object is the first parameter as the method:
SomeClass::bar($i, 'world');
Perl doesn't have classes. It has namespaces that you change with package. For the complete details of Perl OOP, see Intermediate Perl or Object Oriented Perl. You can also see the perltoot and perlboot documentation. In short, Perl fakes what people expect "real" classes to be with packages, normal subroutines, and references.
A module is a distributable piece of code contained in a file. See perlmod.
I say more about this in my post for The Effective Perler, Find a module's release managers. I don't get into the OO stuff, but I talk about the other terms around "module".
Related
I've to use perl as a part of our internship, I've come across this piece of code and could not understand what this may mean.
$val->ReadSim($first_sim, \&DataProcessing);
In the script, subroutine DataProcessing is defined, but could not find ReadSim. I tried searching in our infrastructure but was not able to. This was given to me to understand a week ago and I can't ask the guide without losing credits...
Please help...
What you're seeing is not a mere subroutine, but a method on some object called $val.
I take it you might see something on top of the program like this:
use Foo::Bar; # Some Perl module
This Perl module will contain the method ReadSim. Somewhere in your code, you probably see something like this:
my $val = Foo::Bar->new; # If the people who wrote this followed standards...
This defines $val as an object of Foo::Bar. If you look in package Foo::Bar, you'd see something like this:
#! Foo/Bar.pm
package Foo::Bar;
use strict; # Because I'm an optimist
use warnings;
...
sub new {
my $class = shift;
...
my $self = {};
...
bless $self, $class;
...
return $self; # May simply be bless {}, $class;
}
Then further down, you'll see:
sub ReadSim {
my $self = shift;
...
}
The $self = {} is a reference to a Perl hash. This is how most objects are defined. That's pretty much all the constructor does. It defines a reference to something, then blesses it as that object type. Then, the methods are merely subroutines that take the defined object and manipulate that.
$val-> ReadSim(...);
is equivalent to:
Foo::Bar::ReadSim( $val, ... );
So much for your introduction to Object Oriented Perl by Fire. You still have a question about what does ReadSim mean.
If all is right in the world, the developer of that module should have created built in Perl documentation called POD. First, determine the type of object $val is. Look where $val is defined (Something like my $val = Foo::Bar->new(...);). The Foo::Bar is the class that $val is a member of. You can do this from the command line:
$ perldoc Foo::Bar
And, if you're lucky, you'll see the documentation for Foo::Bar printed out. If you're really, really lucky, you will also see the what ReadSim also does.
And, if you're not so lucky, you'll have to do some digging. You can do this:
$ perldoc -l Foo::Bar
/usr/perl/lib/perl5/5.12/Foo/Bar.pm
This will print out the location of where the Perl Module resides on your system. For example, in this case, the module's code is in /usr/perl/lib/perl5/5.12/Foo/Bar.pm. Now, you can use an editor on this file to read it, and search for sub ReadSim and find out what that subroutine ... I mean method does.
One final thing. If you're new to Perl, you may want to look at a few tutorials that come with Perl. One is the Perl Reference Tutorial. This tutorial will tell you about references. In standard Perl, there are three different types of variables: scalar, hashes, and arrays. To create more complex data structures, you can create hashes of hashes or hashes of arrays, or arrays of arrays, etc. This tutorial will teach you about how to do this.
Once you understand references, you should read the tutorial on Perl Object Oriented Programming. Object Oriented Perl uses references to create a simulated world object oriented programming design. (I say simulated because some people will argue that Object Oriented Perl isn't really object oriented since you don't have things like private methods and variables. To me, if you can think in terms of objects and methods as you program, it's object oriented).
I was appalled to discover today that one of my perl modules uses another module, but doesn't import it.
However, I was shocked when I realized that this has never caused any problems!
The code is something like:
package This;
# no import for OTHER !!
sub new {
... implementation ...
my $something = OTHER->new(#arguments); # no error!
... more implementation ...
}
So what gives? None of This's imports import OTHER -- that was the first thing I checked.
Could it be that if the code that imports This also imports OTHER, OTHER is available to This?
Clarification of question:
X, Y, and Z are modules.
in X: use Y;
in X: use Z;
Y does not use Z
Does Y have access to the functions and methods in Z (and vice versa)?
Your use of the term "import" is a bit misleading.
Does Y have access to Z without importing it (and vice versa)?
Yes, more or less. useing a module just loads it into the current script; all used modules are loaded into the same script, so can see each other (provided they're used in the right order).
But true imports — the things that a module actually exports, so that they're copied into the useing module's namespace — will only be copied into the useing module's namespace.
For example, consider this Perl script:
use Time::HiRes 'time';
package Foo;
sub time1() { return time(); } # calls the built-in time() function
sub time2() { return Time::HiRes::time(); }
package main;
print Foo::time1(), "\n"; # prints (e.g.) 1323048440
print Foo::time2(), "\n"; # prints (e.g.) 1323048440.80571
print time(), "\n"; # prints (e.g.) 1323048440.8061
It uses the Time::HiRes module, and tells it to export Time::HiRes::time into the current namespace (the main namespace), overwriting the built-in time. (Time::HiRes::time is like time, but it has sub-second resolution; it'll give something like 1323048440.80571 instead of just 1323048440.) So package Foo can see Time::HiRes, and anything within Time::HiRes, such as its time; but it has to explicitly specify that, by explicitly writing Time::HiRes::time.
(Note: I wrote the above as a single script, for simplicity of description, but the same thing happens when Foo is defined in Foo.pm and loaded using use Foo;.)
Yes, at least when you use indirect package and object syntax. From calls like
OtherPackage->method()
$anOtherPackageObject->method()
Perl can resolve a fully qualified subroutine name (&OtherPackage::method in both of the above cases) and invoke the subroutine from anywhere.
I try to intercept nonexistent methods call in some subclass.
Yes, I know about AUTOLOAD,
but (for methods) it try to call parent::method first, then UNIVERSAL::method and only then ::AUTOLOAD.
But I need call (something like) ::AUTOLOAD at first.
Because I want to know what methods subclass try to call from parent.
Give me some advice about it please.
If you just want to know what methods are being used, you can use some profiling module like Devel::NYTProf.
If you want to react to that during your program execution, you can intercept directly the entersub opcode just as the profiling modules do. See the perlguts or profiling module code for more details.
You could probably create a 'Monitor' class with FETCH and EXISTS and tie it to the symbol table hash like: tie %Module::Name:: , Monitor;
But unless we know exactly what you are trying to do and why, it's hard to guess what would be the right solution for you.
Please heavily consider Jiri Klouda's suggestion that you step back and reconsider what you are trying to accomplish. You almost never want to do what you're trying to do.
But, if you're really sure you want to, here's how to get enough pure Perl rope to hang yourself...
The subs pragma takes a list of sub names to predeclare. As tchrist says above, you can predeclare subs but never actually define them. This will short-circuit method dispatch to superclasses and call your AUTOLOAD immediately.
As for the list of sub names to pass to the pragma, you could use Class::Inspector->methods (thanks to Nic Gibson's answer for teaching me about this module).
According to brian d foy's comment to Nic Gibson's answer, Class::Inspector will not handle methods defined in UNIVERSAL. If you need to do those separately, you can get inspiration from the 'use subs' line in my Class::LazyObject module.
Why not create an AUTOLOAD sub in the sub-class package which 1) reports the missing method and then 2) dispatches the call to the parent. For this to work you don't defined #ISA in the sub-class.
Something like:
package my_parent;
sub foo { warn "in my_parent::foo" }
package my_subclass;
my $PARENT_CLASS = "my_parent"; # assume only one parent
# Note: no #ISA defined here
sub AUTOLOAD {
warn "non-existent method $AUTOLOAD called\n";
my $self = shift;
(my $method = $AUTOLOAD) =~ s{.*::}{};
my $super = $PARENT_CLASS . '::' . $method;
$self->$super(#_);
}
package main;
my $x = bless {}, 'my_subclass';
$x->foo;
The syntax: $self->$super(#_) where $super has double-colons in it tells perl in which package to start looking for the method, e.g.:
$self->my_parent::foo(...)
will look for the foo method starting in the package my_parent regarless of what class $self is blessed into.
Lets say you have a parent Perl class in one file:
#!/usr/bin/perl
package Foo;
use strict;
use warnings;
use Data::Dumper;
sub new{
my $class = shift;
my %self = ();
return bless %self, $class;
}
1;
and a subclass in a different file:
#!/usr/bin/perl
package Bar;
use base "Foo";
1;
Will the subclass inherit the use statements from the parent? I know the method new will be inherited.
Basically I am trying to reduce the amount of boilerplate in my code and I can't find a clear answer to this question.
You asked in a comment about Test::Most and how it reduces boilerplate. Look at its import method. It's loading the modules into its namespace, adding those symbols to #EXPORT, then re-calling another import through a goto to finally get them into the calling namespace. It's some serious black magic that Curtis has going on there, although I wonder why he just didn't use something like import_to_level. Maybe there are some side effects I'm not thinking about.
I talk quite a bit about this sort of thing in Avoid accidently creating methods from module exports in The Effective Perler. It's in a different context but it's some of the same issues.
Here's a different example.
If some other module loads a module, you have access to it. It's not good to depend on that though. Here are three separate files:
Top.pm
use 5.010;
package Top;
use File::Spec;
sub announce { say "Hello from top!" }
1;
Bottom.pm
package Bottom;
use parent qw(Top);
sub catfiles { File::Spec->catfile( #_ ) }
1;
test.pl
use 5.010;
use Bottom;
say Bottom->catfiles( qw(foo bar baz) );
say File::Spec->catfile( qw( one two three ) );
I only load File::Spec in Top.pm. However, once loaded, I can use it anywhere in my Perl program. The output shows that I was able to "use" the module in other files even though I only loaded it in one:
Bottom/foo/bar/baz
one/two/three
For this to work, the part of the code that loads the module has to load before any other part of the code tries to use that module. As I said, it's a bad idea to depend on this: things break if the loading sequence changes or the loading module disappears.
If you want to import symbols, however, you have to explicitly load the module you want while you are in the package you want to import into. That's just so the exporting module defines the symbols in that package. It's not something that depends with scope.
Ah, good question!
Will the subclass inherit the use statements from the parent?
Well this depends on what you mean by inherit. I won't make any assumptions until the end, but the answer is maybe. You see, perl mixes the ideas of Classes, and Namespaces -- a package is a term that can describe either of them. Now the issue is the statement use all it does is force a package inclusion, and call the targets import() sub. This means it essentially has unlimited control over your package - and by way of that your class.
Now, compound this with all methods in perl being nothing more than subs that take $self as a first argument by convention and you're left with perl5. This has an enormous upside for those that know how to use it. While strict is a lexical pragma, what about Moose?
package BigMooseUser;
use Moose;
package BabyMooseUser;
our #ISA = 'BigMooseUser';
package Foo;
my $b = BabyMooseUser->new;
print $b->meta->name;
Now, where did BabyMooseUser get the constructor (new) from? Where did it get the meta class from? All of this is provided from a single use Moose; in the parent class (namespace). So
Will the subclass inherit the use statements from the parent?
Well, here, in our example, if the effects of the use statement are to add methods, than certainly.
This subject is kind of deep, and it depends if you're talking about pragmas, or more obscure object frameworks, or procedural modules. If you want to mitigate a parents namespace from affecting your own in the OO paradigm see namespace::autoclean.
For boilerplate reduction, I have a couple of strategies: Most of my classes are Moose classes, which takes care of OO setup and also gives me strict and warnings. If I want to have functions available in many packages, I'll create a project specific MyProject::Util module that uses Sub-Exporter to provide me with my own functions and my own interface. This makes it more consistent, and if I decide to change the Dumper (for example) later for whatever reason, I don't have to change lots of code. That'll also allow you to group exports. A class then usually looks something like this:
package Foo;
use Moose;
use MyProject::Util qw( :parsing :logging );
use namespace::autoclean;
# class implementation goes here
1;
If there's other things you regard as boilerplate and want to make simpler to include, it of course depends on what those things are.
A pragmatic answer to your problem: Either use, or look at how Modern::Perl does it to enforce strict and warnings.
You can get a definitive answer by examining the symbol tables for each package:
# examine-symbol-tables.pl
use Bar;
%parent_names = map{$_ => 1} keys %Foo::;
%child_names = map{$_ => 1} keys %Bar::;
delete $parent_names{$_} && ($common_names{$_} = delete $child_names{$_}) foreach keys %child_names;
print "Common names in symbol tables:\n";
print "#{[keys %common_names]}\n\n";
print "Unique names in Bar symbol table:\n";
print "#{[keys %child_names]}\n\n";
print "Unique names in Foo symbol table:\n";
print "#{[keys %parent_names]}\n\n";
$ perl inherit.pl
Common names in symbol tables:
BEGIN
Unique names in Bar symbol table:
ISA isa import
Unique names in Foo symbol table:
Dumper new VERSION
I have a number of different sites that I download data from and massage into other formats (using Perl) for use at work, that are all run from one Perl script kinda like so:
#! /usr/bin/perl
use strict;
use My::Package1;
use My::Package2;
my $p1 = My::Package1->new;
$p1->download;
my $p2 = My::Package2->new;
$p2->download;
and so on and so forth. At the moment each My::Package is its own package; it doesn't inherit from a base package or anything. I am planning to re-write them using Moose and I was hoping that rather than having to edit the Perl script that runs the download each time a new package is added, there might be a way of finding packages that inherit from a base package, and then in a loop instantiate each and do the downloading, kinda like so:
#! /usr/bin/perl
use strict;
for my $pname (packages_that_inherit_from("My::Package")) {
my $package = $pname->new;
$package->download;
}
Is it, or something ilke it, possible?
TIA
Using Moose's Class::MOP underpinning you can find the subclasses assigned to each class (at that point in time).
From Class::MOP::Class docs:
$metaclass->subclasses
This returns a list of all subclasses for this class, even indirect subclasses.
$metaclass->direct_subclasses
This returns a list of immediate subclasses for this class, which does not include indirect subclasses.
So for example if we build these classes:
{
package Root;
use Moose;
use namespace::clean -except => 'meta';
sub baz { say 'Some root thingy' }
sub download { say "downloading from " . __PACKAGE__ }
}
{
package NodeA;
use Moose;
extends 'Root';
use namespace::clean -except => 'meta';
sub download { say "downloading from " . __PACKAGE__ }
}
{
package NodeA1;
use Moose;
extends 'NodeA';
use namespace::clean -except => 'meta';
sub download { say "downloading from " . __PACKAGE__ }
}
Then using your example as a basis we can do this:
for my $pname ( Root->new->meta->direct_subclasses ) {
my $package = $pname->new;
$package->download;
}
# => "downloading from NodeA"
So above runs NodeA->download. Changing above to meta->subclasses would also run the NodeA1->download.
/I3az/
Although you say you are moving to Moose, a non-Moose way is to put all the derived packages in the known subdirectory based on the base package name. You then load all of the modules
For instance, if your base package is Local::Downloader, all the derived packages start with Local::Downloader::Plugin or something similar. You then look for all modules in your #INC that much .../Local/Downloader/Plugin/.... Although it's not too hard to do yourself, something like Module::PluginFinder can do it for you too.
What you are asking for wont be possible because none of the packages you are looking to use will be loaded yet. Why not place all of the packages in a common directory, and then have your script open that directory, and for each file, require it, and then instantiate your objects.
There's no way to do this based on inheritance because the parent class doesn't even know if it has descendants, never mind how many it has or what their names are.
However, if you follow the common convention of using hierarchal namespaces and naming the descendants as Parent::Foo, Parent::Bar, etc., you can approximate this by using Module::Pluggable to load up everything under the Parent namespace:
use Module::Pluggable require => 1, search_path => ['Parent'];
my #descendants = plugins();
Since this is based on the namespaces, though, it will pull in Parent::Helper::ThatIsNotAChild, while missing Child::NotUnder::Parent::Namespace, so it's not entirely perfect.