naming modules

[Cross-posting to news:comp.lang.perl.misc, 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.

--
FSF associate member #7257

Quoth Ivan Shmakov <oneingray@gmail.com>:
> [Cross-posting to news:comp.lang.perl.misc, 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)?

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::Protocol::*, for instance,
or quite a few of the DBD modules.

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

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

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.

> 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?

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

Ben

>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:

[...]

>> 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::Protocol::*,
> for instance, or quite a few of the DBD modules.

ACK. Thanks!

However, for LWP::Protocol::* 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.

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

> 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?

>> 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?

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

--
FSF associate member #7257

On 2012-03-26 10:24, Ivan Shmakov wrote:

> 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

--
Ruud

Quoth Ivan Shmakov <oneingray@gmail.com>:
> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>
> Unfortunately, even though I dislike mixed-case identifiers, I
> have no good reason at hand to avoid it for my Perl code.

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 .

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

Yes, though in practice new core module tend to start on CPAN and then
migrate in, nowadays.

> >> The other question is whether I should use foo::bar or
> >> App::Foo::Bar for the modules related to an application Foo?
>
> > 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?

If there's no more specific top-level that fits, then yes, that sounds
good.

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

Ben

Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Ivan Shmakov <oneingray@gmail.com>:
>> >>>>> Ben Morrow <ben@morrow.me.uk> writes:
>> >>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:
>>
>> Unfortunately, even though I dislike mixed-case identifiers, I
>> have no good reason at hand to avoid it for my Perl code.
>
> 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,
justuseasequenceoflettersandletthereaderworryabout breakingitupinordertoreconstructwords,
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.

In article <867gy7rick.fsf@gray.siamics.net>, Ivan Shmakov
<oneingray@gmail.com> wrote:

> [Cross-posting to news:comp.lang.perl.misc, 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?A..._namingmodules

>>>>> brian d foy <brian.d.foy@gmail.com> writes:
>>>>> Ivan Shmakov <oneingray@gmail.com> wrote:

[...]

>> 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?A..._namingmodules

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

--
FSF associate member #7257

>>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>> Quoth Ivan Shmakov <oneingray@gmail.com>:

[...]

>> 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/

--
FSF associate member #7257