How to structure a perl application

[Henry Law]

I'm about to start writing an application in perl and need advice on
structuring it. When I wrote my first V*sual B*sic application the
code worked, mostly, but I virtually had to re-write it to undo the
bad structure I'd unwittingly used and I don't want to do that again.

I Googled a bit ([perl application structure] for example) without
finding much; can someone suggest a source of information?

If not, would it be OK for me to present my current ideas (a
combination of packages, separate files of code brought in via
"require", and judiciously chosen package global variables) for
consideration and refinement?

(When all's said and done this I'm not a professional and this code
will probably only ever be for my own use, so enterprise-wide code
management processes probably aren't appropriate. But I want to take
pride in what I'm doing ...)

Henry Law <>< Manchester, England

 

[Simon Taylor]

Hello Henry,

I'm about to start writing an application in perl and need advice on
structuring it. When I wrote my first V*sual B*sic application the
code worked, mostly, but I virtually had to re-write it to undo the
bad structure I'd unwittingly used and I don't want to do that again.

I Googled a bit ([perl application structure] for example) without
finding much; can someone suggest a source of information?

You might the following useful:

perldoc perlstyle
perldoc perlmodlib (See the section
"Modules: Creation, Use, and Abuse")

And also the article archive at perl.com:

http://www.perl.com/pub/q/Article_Archive

Hope this helps,

Simon Taylor

 

[Anno Siegel]

I'm about to start writing an application in perl and need advice on
structuring it. When I wrote my first V*sual B*sic application the
code worked, mostly, but I virtually had to re-write it to undo the
bad structure I'd unwittingly used and I don't want to do that again.

I Googled a bit ([perl application structure] for example) without
finding much; can someone suggest a source of information?

A Perl application is usually just a short script that makes use
of one or more modules to accomplish a task. You want to learn
about perl module structure. Googling for that and taking it from
there is going to bring up more.

A few pertinent docs have also been mentioned in this (and "your" other)
thread.

There are also modules that help building new modules, but
I think I'm not quite up-to-date on that. I'm using (a derivate of)
ExtUtils::ModuleMaker, fwiw.

If not, would it be OK for me to present my current ideas (a
combination of packages, separate files of code brought in via
"require", and judiciously chosen package global variables) for
consideration and refinement?

General invitations like "improve this code" don't work very well
in Usenet groups. Of course, I'm just generalizing my personal
attitude, but specific questions work better.

(When all's said and done this I'm not a professional and this code
will probably only ever be for my own use, so enterprise-wide code
management processes probably aren't appropriate. But I want to take
pride in what I'm doing ...)

Well, from one Amateur to another, plan to throw a few attempts away.
Make runnable prototypes fast (with stub routines wherever possible)
to see the structure of the whole. Be ready to start over before
filling in every detail when it becomes apparent that the current
structure has serious drawbacks.

You can use the previous code as a quarry, that's when some copy/paste
programming is in order. But be careful not to introduce inconsistencies
or perpetuate existing ones. In doubt, re-write.

Modular software structure is a bit of an art form, never mind the
language you are using, and some of it is only learned from experience.
Sometimes, gaining specific experience with a particular project is
in order. Your latest design is your best one

Anno

 

[thumb_42]

I'm about to start writing an application in perl and need advice on
structuring it. When I wrote my first V*sual B*sic application the
code worked, mostly, but I virtually had to re-write it to undo the
bad structure I'd unwittingly used and I don't want to do that again.

I Googled a bit ([perl application structure] for example) without
finding much; can someone suggest a source of information?

If not, would it be OK for me to present my current ideas (a
combination of packages, separate files of code brought in via
"require", and judiciously chosen package global variables) for
consideration and refinement?

(When all's said and done this I'm not a professional and this code
will probably only ever be for my own use, so enterprise-wide code
management processes probably aren't appropriate. But I want to take
pride in what I'm doing ...)

Thats a tall order!

It'll really depend on what the application does.

In general, always use strict, package stuff into modules, don't use global
variables, make all methods "private" or "protected" (in perl that typically
means finding a naming convention and sticking to it)

Example (the way I do it these days):

$obj->_protected(@args)
&_private($object,@args)

But, there will probably be 100 other ways each of which with their own ups
and downs.

Try not to let the main "kicker script" get to large. Something like:

[Note: I'm using "psuedo-code" that only "looks like" perl]

#!/usr/bin/perl
use strict;
use MySpace::MyApp;
use vars qw(%CONF);

.. This is the command-line script..
&main();
sub main {
.. Load %CONF .. or make %CONF $CONF and use an object, depending
.. on if conf needs dynamic updates..
my($app) = new MySpace::MyApp(%CONF);
eval {
$app->run(@ARGV);
};
if($@){
.. Do something with error, but DON'T ignore it...
}
}

Where your application code resides in MySpace::MyApp.

Another thing to look into is the "Model-View-Controller" design pattern, if
it's web based (or based on command line arguments, or XML documents,
Keypresses or ... )

The general idea is to determine what part of an application to run depending
on a certain "actor" in a web app, the "Actor" could be the request URI of
the presence of a form variable. In other cases, it's a key sequence that was
pressed. (or other user input) Could also be based on command line arguments.

In perl the "Actions" typically are callback subs, but they could also be
packages that inherit from a common "Action.pm" type of package.

In general, avoid this:

if($keq eq 'A'){
.. commands ..
}elsif($key eq 'B'){
.. commands ..
}...
...
...($key eq 'Z'){
.. commands ..
}

(The above is OK if you only have a few "Actions" but it gets very unruly
over time, imagine a web server that did that for every URL, you get the
idea..)

There are a lot more things to consider, of course.

Jamie