Hello World for module writers

[Anonymous Monk]

Hello World is a common introduction in programming. I can write "Hello World" in many computer languages. I am trying to produce a Perl module. "Hello World" is escaping me. I've been google'ing for hours, and not getting close. But I see other people struggling with similar issues.

I think it would be nice if there was a Hello::World module, which anyone who is registered in CPAN/PAUSE could edit, to provide the current best practice as far as making a module goes.

I decided to rewrite an old module, because I think I need to inherit it, for something else I am writing. To republish it on CPAN, I thought I should at least see what Perl::Critic thinks of it, and it has a problem with AUTOLOAD. It seems that Devel::SelfStumper is the solution, but the POD for that is completely opaque to me. And I've looked for tutorials and HOWTOs on Devel::SelfStumper, and there is nothing.

At some point, I will figure out how to make everything in my module inheritable. But, I think it wold be nice if a Hello::World module (which is kept up to date) would do this.

Starting at the Z end of my cpan/build, I am about 25% through things. And I am not seeing anything about autogenerated functions, in particular get/set.

If someone knew of a particularly good example of of SelfLoader and Devel::SelfStepper, that would be wonderful.

Thanks!

[davido]

You're really asking several questions here. The first (I think) is how to create a minimal module as a learning experience for how to create a CPAN distribution. My suggestion there is to go ahead and create Acme::HelloWorld (or something else simple). Nobody's going to care if you mess it all up the first time. Nobody will expect anything. Nobody will even know or care about it until some day someone else searches CPAN to see if a module by that name exists. The Acme namespace is for joke modules. But it's the closest thing we have to a namespace for learning. When you're done with it, just delete it from CPAN again. It will remain on Backpan, but nobody is going to care at all about some throw-away Acme:: module on backpan.

There are many resources available for how to start a new module. Module::Starter can point you in the right direction if you intend to use ExtUtils::MakeMaker. There are plenty of other ways to do it, but that's the starting point that many have used, and will expose you to enough to of the nitty-gritty details that you can learn the mechanics of what some of the other methods abstract away. I think it's worth learning some of those details. Also, go find a few fairly simple distributions and observe their directory structure, the source code, the contents of the files that make up the distribution. Learn "how they do it."

Sam Tregar wrote a book, Writing Perl Modules for CPAN. Amazon has used copies starting at under $2.00US, plus shipping. It's a little outdated, but a nice starting point. perlmodstyle is also helpful.

Next -- maybe I'm misunderstanding -- but it seems like you think that a CPAN distribution needs to delay loading of its functions until they're invoked at runtime. AutoLoader, and SelfLoader facilitate this. However, in my experience these sorts of solutions don't carry the importance they did back in the days where CGI (non-persistent, frequently invoked processes) reined supreme. While quick startup time is probably still relevant in some applications, the original justification (quick startup for CGI apps) has become obsolete, replaced by modern frameworks that run as persistent processes. In those sorts of environments there's much less advantage to delayed sub loading, and even, some disadvantages (not the least of which is useless complexity). In a persistent process one would probably gladly trade a little startup time to gain a better runtime experience.

You mentioned inheriting a module (taking it over to maintain it, I think) and rewriting the whole thing. First mistake. If it works, don't rewrite it. If it needs some bug fixes, fix them. "Get in, get out, get paid." Now if the goal is "refactor only as much as necessary to improve maintainability", that's probably a reasonable motivation. Watch Schwern's talk on Skimmable Code. But first, focus on beefing up the test suite to expose regressions you will inevitably introduce along the way.

Finally, you mentioned using Devel::SelfStubber in place of the existing AUTOLOADing that's going on in the module. Please don't introduce the complexity of another dependency (yes, I'm aware it's in the core) to rewrite and replace what might be complex code, that's already working. Perl::Critic provides suggestions. A suggestion is to not use AUTOLOADER. That's pretty good advice, in general. But trading AUTOLOADER for something even more complex, under-documented, and less well understood, just because it's obscure enough that Perl::Critic doesn't pay attention to it is definitely a bad practice.

[eyepopslikeamosquito]

As for good ways to create CPAN modules, some relevant PM nodes are:

• José's Guide for creating Perl modules
• Best Module Starter?
• How to make a CPAN Module Distribution
• Simple Module Tutorial
• Writing Solid CPAN Modules

Some external references:

• Writing Perl Modules for CPAN, book by Sam Tregar (free download should be available too)
• Guide to Creating Perl Modules by Ken Williams
• Perl Module Mechanics by Steven McDougall
• Making Perl Reusable with Modules by Andy Sylvester
• Making New Distributions by brian d foy (using Template Toolkit)

[davido]

I wanted to also give a step by step guide on creating a minimal Hello World module. There are many ways to do it. And everyone has their own process. When first learning, I like the fact that the approach I'm about to outline gets you started rapidly, but doesn't hide the implementation details that are good to learn. When you move up the ladder of abstraction to a higher-level set of tools, it will still be valuable to have learned what's going on at this lower level.

Read more... (6 kB)

Do also familiarize yourself with what the other tests in the t/ folder do. For more elaborate modules your test suite should grow much larger. The test files will run in ascii-betical order. When tests fail, sometimes it's helpful to run one test file individually: $ perl -Mblib t/00-load.t. In particular, I find that sometimes prove jumbles the order of output when the test suite spits out messages both to STDERR and STDOUT. By invoking a test directly in the Perl interpreter, that problem goes away, and it becomes easier to figure out what's going wrong.

Get comfortable with a version control system, and start checking your modules into repos.

Remember; before uploading to CPAN again, always bump the version number. Even if you made no other changes; you should never upload the same version number twice, and version numbers should always be greater than the last number used.

Other useful documents: perlmodstyle, Test::More, CPAN Testers Author Notes, and the following books: Intermediate Perl, Test Driven Development: A Developer's Notebook

Have fun!

[chromatic]

The best example of SelfLoader is not to use it. It adds complexity for almost no benefit.

I don't know what Devel::SelfStepper or Devel::SelfStumper are.

[tye]

I believe that SelfStepper and SelfStumper are two different mispelings of Devel::SelfStubber (which looks to be about as bad of an idea as any of the "delay compiling module code" "solutions").

I'll also note that I expect Damian Conway to be rolling over in his gravebed with how his extensive efforts to discourage Perl Best Practices from being mindlessly used to arbitrarily enforce "standards" upon code has been translated into Perl::Critic which is being repeatedly used without first reviewing the rules and deciding which to adopt and then the reaction to a notice of a rule violation is repeatedly that people jump to a knee-jerk stampede away from the criticized practice without a demonstration of even understanding the reason for the rule and also paying no attention to how much worse the supposed solution is (since it doesn't trigger any objection from Perl::Critic).

Perhaps the next edition of Perl Best Practices can declare that a relatively mindless application of Perl::Critic has clearly become a "worst practice" and this can then be mindlessly translated into a Perl::Critic rule that mindlessly rejects the use of Perl::Critic.

That idea was created as a joke. But having a default Perl::Critic rule that yells at you for using Perl::Critic without having first evaluated the rules and selected which ones make sense in your environment, would actually be a better idea than a lot of Perl::Critic rules that I've run into so far by watching people run away from them into worse practices.

[chromatic]

You're never going to go broke underestimating the thoughtless application of advice to programming.

[2teez]

Hi,

"I am trying to produce a Perl module. "Hello World" is escaping me..." HOW?
"... if there was a Hello::World module..."

Really, why would anyone want to write "Hello, World" as a module?
When such task can be achieved in a one-liner as shown previously. However, who knows? To the longings of the heart, who can tell?
Below is a head up.
If you want to produce a module Hello::World, create a folder called Hello, and then inside the folder make a perl module named "World.pm". ( In my case, I have two namely: "World.pm" and "World2.pm" )
Hello/World.pm contains the following lines:


package Hello::World;
use warnings;
use strict;
use Exporter;

our @ISA    = qw(Exporter);
our @EXPORT = qw(greetings);

sub greetings {
    return "Hello, World";
}

1;

You can even decide to go the OOP way like so:
Hello/World2.pm contains the following lines:


package Hello::World2;
use warnings;
use strict;

sub new {
    my $class = shift;
    my $self = { greeting => shift, };
    return bless $self, $class;
}

sub the_greetings {
    my $self = shift;
    return $self->{greeting};
}

1;

Make another perl file, say "hello.pl", then use Hello::World therein like so:


#!/usr/bin/perl
use warnings;
use strict;
use Hello::World;
use Hello::World2;  ## OOP

print greetings();  ## prints Hello, World

print $/;

my $greet = Hello::World2->new("Hello, World, Again");
print $greet->the_greetings();  ## prints Hello, World, Again

You can get more info. from perlmod, perlmodlib and several other books and tutorials onlines.
I can only hope this turn on the bulb!:)

[philiprbrenan]

Please consider:

h2xs -ACPX -n Hello::World -v 1.0);

h2xs is part of the Perl kit and will make a bare pure perl (no C code) module for you. Fill in your perl code, write some tests, and then:

perl Makefile.PL
make dist

[Khen1950fx]

There is no Devel::SelfStumper. Think about it...would you really want to waste time stumping yourself?-:). I think that you meant Devel::SelfStubber.

[Riales]

Edit: Definitely should've read the OP more closely. Now I see that it was more about building modules and less about writing another "Hello, world!" program. Sorry. I'm leaving this up for posterity, I guess.

I think there's no module for it because there really isn't any need...

$ perl -e 'print "Hello, world!"'
Hello, world!

Fin.