Re: Hello World for module writers

[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.