naming modules

[Ivan Shmakov]

[Cross-posting to as
news:comp.lang.perl.modules doesn't seems too active.]

I've decided to put certain Perl sources to CPAN, but I'm having
trouble inventing some nice names for them.

In particular, I understand that a module name shouldn't be
comprised of just the lowercase letters, so to avoid a potential
name clash with a future Perl pragma. However, is there a
reason to avoid all-lowercase names containing colons (as in,
e. g., common::sense)?

The other question is whether I should use foo::bar or
App::Foo::Bar for the modules related to an application Foo?

And then the third one. I intend to provide a module to compute
multiple SHA digests at the same time (as may be used, e. g., to
generate Debian list files.) The working title is
Digest::SHA::combined, but I wonder if I should use
Digest::SHA::Combined for consistency instead?

TIA.

 

[Ivan Shmakov]

[...]

In particular, I understand that a module name shouldn't be
comprised of just the lowercase letters, so to avoid a potential
name clash with a future Perl pragma. However, is there a reason to
avoid all-lowercase names containing colons (as in, e. g.,
common::sense)?

I would say that module names with the first part all in lowercase
should be considered reserved: the core has warnings::register, for
instance, and there are version::AlphaBeta and version::Limit on CPAN
which are subclasses of version. OTOH there are quite a lot of
modules with parts after the first in lowercase: LWP:rotocol::*,
for instance, or quite a few of the DBD modules.

ACK. Thanks!

However, for LWP:rotocol::* it's due to the fact that the URI
schema names are all-lowercase themselves, I suppose.

Unfortunately, even though I dislike mixed-case identifiers, I
have no good reason at hand to avoid it for my Perl code.

common::sense considers itself to be pragmatic in nature, since all
it's doing is turning on various core pragmas.

There still is a potential clash should the Perl developers
choose to implement their own common::sense.

App:: is for implementations of applications, not modules which
relate to them. So, for instance, App::Ack implements the guts of
ack(1), rather than being an interface for calling it.

Actually, there's to be the modules that handle a format, or
perhaps a faimily of formats, specific to this particular
application.

If App::MyApp::MyFormat doesn't fit, should it be, e. g.,
Data::MyApp::MyFormat?

Yes. Unless you've got a good reason not to, go with WikiWords with
initial caps and no underscores.

Having C, Shell and Lisp dialects as my "programming
background", I find it quite hard to write in CamelCase.

PS. I'll try to file an RT ticket against Digest::SHA on whether my
module could be added to the distribution.

 

[Dr.Ruud]

Unfortunately, even though I dislike mixed-case identifiers, I
have no good reason at hand to avoid it for my Perl code.

PACKAGE PurgeAndArchive;

use strict;
use warnings;

our $VERSION; BEGIN { $VERSION = "0.99" }

my %_cache;

....

1; # satisfy require

 

[Rainer Weikusat]

I find them quote convenient for package names, even though I dislike
them for function and variable names: they're different enough from the
norm to stand out a bit. <shrug> Maybe I'm just used to it .

I'm usually opposed to camel case because I'm convinced that there's a
good reason that the writing style of the Romans,
justuseasequenceoflettersandletthereaderworryaboutbreakingitupinordertoreconstructwords,
was abandoned a long time ago. OTOH, the Perl convention is such that
camel case is supposed to be used for module names and sticking to an
existing convention in areas of minor relevance is better than
inventing a new one.

Random piece of information: Reportedly, the mixed-case convention was
originally invented to work around the fact that the keyboard used for
the Xerox Alto lacked an underscore key.

 

[brian d foy]

[Cross-posting to as
news:comp.lang.perl.modules doesn't seems too active.]

I've decided to put certain Perl sources to CPAN, but I'm having
trouble inventing some nice names for them.

We have some naming advice at:

https://pause.perl.org/pause/query?ACTION=pause_namingmodules

 

[Ivan Shmakov]

[...]

I've decided to put certain Perl sources to CPAN, but I'm having
trouble inventing some nice names for them.

We have some naming advice at:

https://pause.perl.org/pause/query?ACTION=pause_namingmodules

Indeed, I've read it first. But it didn't answer some of my
questions.

 

[Ivan Shmakov]

[...]

PS. I'll try to file an RT ticket against Digest::SHA on whether my
module could be added to the distribution.

I strongly suspect the answer will be 'no', given that Digest::SHA is
in the core and really rather important (it's part of the CPAN
toolchain, for instance). Still, there's no harm in asking.

This question was briefly discussed on CPAN RT [1] and it was
decided to implement a more generic Digest::combined Perl module
[2], available as a separate distribution, which I've happily
released today [3].

[1] https://rt.cpan.org/Ticket/Display.html?id=76044
[2] http://search.cpan.org/perldoc?Digest::combined
[3] http://search.cpan.org/~onegray/Digest-combined-0.1/