Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Hello World for module writers

by Anonymous Monk
on Aug 31, 2012 at 01:17 UTC ( #990888=perlquestion: print w/replies, xml ) Need Help??

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

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.


Replies are listed 'Best First'.
Re: Hello World for module writers
by davido (Cardinal) on Aug 31, 2012 at 07:40 UTC

    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.


Re: Hello World for module writers
by eyepopslikeamosquito (Chancellor) on Aug 31, 2012 at 05:07 UTC
Re: Hello World for module writers
by davido (Cardinal) on Aug 31, 2012 at 08:46 UTC

    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.

    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!


Re: Hello World for module writers
by chromatic (Archbishop) on Aug 31, 2012 at 01:25 UTC

    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.

    Improve your skills with Modern Perl: the free book.

      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.

      - tye        

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

Re: Hello World for module writers
by 2teez (Vicar) on Aug 31, 2012 at 03:09 UTC

    "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 "". ( In my case, I have two namely: "" and "" )
    Hello/ 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/ 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 "", 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!:)

Re: Hello World for module writers
by philiprbrenan (Monk) on Aug 31, 2012 at 10:52 UTC

    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
Re: Hello World for module writers
by Khen1950fx (Canon) on Aug 31, 2012 at 02:23 UTC
    There is no Devel::SelfStumper. Think about it...would you really want to waste time stumping yourself?-:). I think that you meant Devel::SelfStubber.
Re: Hello World for module writers
by Riales (Hermit) on Aug 31, 2012 at 01:23 UTC

    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!


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://990888]
Approved by toolic
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (4)
As of 2020-02-26 02:08 GMT
Find Nodes?
    Voting Booth?
    What numbers are you going to focus on primarily in 2020?

    Results (113 votes). Check out past polls.