Planning for maintenance

[Derek.Moody]

Background:
I have a couple of dozen perl scripts to reconcile. It seems they grew on
an ad-hoc basis and there is a good deal of duplicated content some of which
has been allowed to get out of step. For ease of maintenance I am
extracting these into two or three modules. I anticipate future
developments requiring at least as many new scripts and another three or
four modules so that no one script will require more than two, or
perhaps three of these modules.

The question:
For ease of future maintenance, especially for (s)he who may come after me -
* Do I import all subroutines and data so that the call might be
&dosomething($parameter);
* Or do I use full references
&Foo::dosomething($Bar:arameter);
Especially as some variable names will be duplicated in alternate packages.

Opinions solicited:
If you were hired to maintain my legacy (say 50 scripts, 8 modules) which
form would you prefer?
As you may guess I favour the second version - am I overlooking any
potential pitfalls?

Tia. Cheerio,

--

 

[Tassilo v. Parseval]

Also sprach Derek.Moody:

I have a couple of dozen perl scripts to reconcile. It seems they grew on
an ad-hoc basis and there is a good deal of duplicated content some of which
has been allowed to get out of step. For ease of maintenance I am
extracting these into two or three modules. I anticipate future
developments requiring at least as many new scripts and another three or
four modules so that no one script will require more than two, or
perhaps three of these modules.

The question:
For ease of future maintenance, especially for (s)he who may come after me -
* Do I import all subroutines and data so that the call might be
&dosomething($parameter);
* Or do I use full references
&Foo::dosomething($Bar:arameter);
Especially as some variable names will be duplicated in alternate packages.

Opinions solicited:
If you were hired to maintain my legacy (say 50 scripts, 8 modules) which
form would you prefer?

I suggest putting all the symnbols into the package's @EXPORT_OK so that
you can import them on demand:

package Your::Module;
use base qw(Exporter);

@EXPORT_OK = qw(dosomething);

sub dosomething { ... }

And when you include the module, you can either do

use Your::Module; # nothing is imported
Your::Module::dosomething();

or

use Your::Module qw(dosomething);
dosomething();

See 'perldoc Exporter' for details.

Tassilo

 

[Eric J. Roode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The question:
For ease of future maintenance, especially for (s)he who may come
after me - * Do I import all subroutines and data so that the call
might be
&dosomething($parameter);
* Or do I use full references
&Foo::dosomething($Bar:arameter);
Especially as some variable names will be duplicated in alternate
packages.

Opinions solicited:
If you were hired to maintain my legacy (say 50 scripts, 8 modules)
which form would you prefer?
As you may guess I favour the second version - am I overlooking any
potential pitfalls?

First of all, you wouldn't (or shouldn't, anyhow) invoke subroutines
with an ampersand (&) unless you have a good reason for doing so.

Second, imho, by fully-qualifying all of the function calls, you're
making a lot of extra typing for yourself, and limiting future
flexibility. If you choose to move half of the function calls to a
different module someday, you'll have to edit all of the function
call invocations to have the new module name, as opposed to simply
changing a declaration or two at the top of each program.

- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32) - WinPT 0.5.13

iD8DBQE/3JiLY96i4h5M0egRAifLAKCSA4pVmVuAIU6le4VUayyh+6XSlQCeIDPf
bl0pjLCG3+3LYKBQZON7fiE=
=M4GZ
-----END PGP SIGNATURE-----

 

[Alan J. Flavell]

Second, imho, by fully-qualifying all of the function calls, you're
making a lot of extra typing for yourself, and limiting future
flexibility. If you choose to move half of the function calls to a
different module someday, you'll have to edit all of the function
call invocations to have the new module name, as opposed to simply
changing a declaration or two at the top of each program.

Indeed. On the other hand, if you'd had the bad-fortune to choose a
function name which later turned out to clash with some other needed
module...

 

[Derek.Moody]

Second, imho, by fully-qualifying all of the function calls, you're
making a lot of extra typing for yourself, and limiting future
flexibility. If you choose to move half of the function calls to a
different module someday, you'll have to edit all of the function
call invocations to have the new module name, as opposed to simply
changing a declaration or two at the top of each program.

I'm not really worried about the amount of typing -I- have to do - most of
the early part of this job is search and replace in any case.

The question is really whether or not maintainability is improved by these
explicit package calls.

Cheerio,

--

 

[Darin McBride]

Indeed. On the other hand, if you'd had the bad-fortune to choose a
function name which later turned out to clash with some other needed
module...

And thus my personal preference: OO perl Name clashing goes down
to zero, although if everyone had a function (method?) foo(), it may
get confusing for the programmer...

 

[Anno Siegel]

Indeed. On the other hand, if you'd had the bad-fortune to choose a
function name which later turned out to clash with some other needed
module...

....all is not lost. This renames a function on import:

use Exporter::Renaming;
use MyModule Renaming => [ clash => 'no_clash'];

Anno

 

[Uri Guttman]

...all is not lost. This renames a function on import:

use Exporter::Renaming;
use MyModule Renaming => [ clash => 'no_clash'];

i had proposed a grant project to TPF for a similar thing. this module
would actually be used by the module writer and not the user. it would
allow a user to either have an OO or procedural interface (similar to
what cgi.pm does) by having a private default object for the OO. but
because it would export names to the user namespace, i wanted to support
renaming in the use line. so the real module would use this (called
class:rocedural) and list the exported names in some global (possibly
@EXPORT) and the user would pass a map (in the use line for the module
they want) of names to renames.

i will have to investigate Renaming to see how it does this. in any
case, the class:rocedural stuff would still be useful if i ever get to
writing it. i can't get grants now that i am on the tpf steering
committee.

uri

 

[Anno Siegel]

[...]

...all is not lost. This renames a function on import:

use Exporter::Renaming;
use MyModule Renaming => [ clash => 'no_clash'];

i had proposed a grant project to TPF for a similar thing. this module
[...]

i will have to investigate Renaming to see how it does this. ...

Simple and brutal -- it commandeers Exporter::import and replaces
it with a modified version of itself that understands renaming.
("no Exporter::Renaming" restores the original.) The modified
import() uses the original one to import everything into a dummy
name space, just to make sure no export restrictions are violated.
Thein the actual renaming happens in so many simple typeglob assignments
into the user's name space.

Anno

 

[ctcgag]

Opinions solicited:
If you were hired to maintain my legacy (say 50 scripts, 8 modules) which
form would you prefer?
As you may guess I favour the second version - am I overlooking any
potential pitfalls?

I think it would depend on how many times per script these things are
used, and how intensive is the maintenance they are likely to need. The
fewer and less, the more I'd favor fully resolved names.


Xho