I just did a pretty major edit to this page. I felt showing just a single object-oriented module, and the mention that procedural style is considered "old", was not a valid representation of the state of writing modules in Perl. Perl is a hybrid language, both OO and procedural styles are considered quite valid, should be used as appropriate and there's large piles of procedural modules on CPAN and being freshly produced. So I added an illustration of a procedural version of Hello::World.
I also made the example a little more interesting by allowing the user to set the target. I felt this illustrates the important difference between an OO and procedural module a little better. It might be overkill, it might not be this articles place to illustrate the differences.
I also changed the POD style a little. I use "=head3" rather than the "=over/=item/=back" style as its much harder to screw up and tends to be rendered better. I've also put in example code preceding each function as I find an illustration (in this case code) is very helpful. However I'd accept the argument that this is not descriptive of how most Perl modules are written and would not object to it being reverted.
I've had the module enforce its version requirement and fleshed out the versioning problems facing a Perl module author, its more like shipping a plugin for an application then a langauge. I used the old style "5.006" syntax because anything before 5.6.0 doesn't understand the triple digit format. One can argue that it'll die either way.
I changed the version number to 1.00. This is because the sorting of module versions is a little confused so its best to choose something that will sort the same as a number and as a string. Thus you want to avoid the 1.9 vs 1.10 problem by starting off with at least two decimal places. 1.09 vs 1.10 is clear.
Otherwise the docs have been fleshed out a bit. I've made a bunch of contrasts with Java, which is about as contrast with Perl as you can get. I felt it necessary to point out that its not necessary to put your code and routines into a module, a point some Java folks might miss.
I've also removed the use of indirect object syntax (my $hello = new Hello::World) as its unnecessarily ambiguous syntax, tends to be more trouble than its worth and things get weird when you start passing in arguments. I realize using indirect object syntax is fairly common for a constructor, but only for the constructor. In no other use is it common. I'd rather remove this extra bit of unnecessary complexity from the example and just not mention it.
Finally, XML::Parser is probably too complicated a module to be used as an example of an OO module. Something simpler and more straight-forward would be nice. Similar problems with DBIx::Class for a mixin. Its all I could think of.
--Schwern 20:41, 19 March 2007 (UTC)
I've put "use strict" and "use warnings" back into the examples. I see they were removed as "cruft". I put in an explanation what they're used for and why they're important for module authors. I feel if we want a full, descriptive example of how a Perl module is written its important we describe actual use and also illustrate the difference between Perl as a quick-script language and Perl for larger projects. It introduces the idea of variable scope which becomes very important for modules.
--Schwern 21:12, 19 March 2007 (UTC)
just a pointer, the module examples don't work as is if you c&p them into files, needed to delete the spaces in front of the =head and =cut lines... you might consider updating that —Preceding unsigned comment added by 68.101.40.214 (talk) 03:41, 6 March 2008 (UTC)
At risk of confusing the fairly casual reader I've added a section specifically on Perl packages and namespaces. I don't know if I've sufficiently put over that while modules rely on the package mechanism, packages are independent of modules if you want them to be. I think I will also add sections on module location and 'Standard' modules.
Ivanberti (talk) 09:32, 18 May 2009 (UTC)
"Furthermore, a module is the Perl equivalent of the class when object-oriented programming is employed".
I'm afraid that's not strictly correct. It's the package that is the equivalent of the class (though I'm sympathetic about the confusion). See this example:
use strict;my $o = X->new();$o->WhatAmI;package X;sub new {return bless \$_[0];}sub WhatAmI {print $_[0];}There's no module involved here. Of course for convenience and for reusability we put the class definition (ie package declaration and relevant subs) in a separate compilation unit and invoke it from our using program. But even then, that doesn't make it a module. Create this compilation unit as A.pl:
package X;sub new {return bless \$_[0];}sub WhatAmI {print $_[0];}1;called from this using program:
use strict;require 'A.pl';my $o = X->new();$o->WhatAmI;The invoked unit is not a module: its package name doesn't correspond with the file name, it doesn't have a '.pm' extension, and it can be invoked with require. Again, of course, for convenience and for clarity we would by convention put the package in a file called X.pm and invoke it as require X; (or use X;).
For the same reasons, I really also have to take issue with the sentence:"Technically, it is a particular set of conventions for using Perl's package mechanism that has become universally adopted"
Ivanberti (talk) 15:59, 18 May 2009 (UTC)
It would be great if someone could define the various uses of "use" not covered by Larry Wall, CPAN or anywhere else. For example, what does it mean to have curly braces after a use? Ever seen something like this?
use My::Confusing::Code{ CITY => { MODIFY => 1, DEFAULT => My::Even::more::complicated->func(), }, STATE => { MODIFY => 1, DEFAULT => 'Concatenate()', }, COUNTRY => { MODIFY => 1, REQUIRED => 0, DEFAULT => 'Gabon', },}What does "use" mean in this context? —Preceding unsigned comment added by Paz9 (talk • contribs) 14:23, 21 July 2010 (UTC)
It says in the article that some code has been added, "...just to make things interesting." That's a sure sign that the author is adding unnecessary cruft, trying to impress or maybe just having fun, rather than trying to explain things as simply as possible. — Preceding unsigned comment added by 81.187.233.172 (talk) 19:34, 29 October 2011 (UTC)