Foo::Bar::Libfoobar vs. Libfoobar?

[Ivan Shmakov]

I'm curious, what's the current preferred naming scheme for Perl
bindings to C libraries? Given such modules as GD or
Image::Magick, I'd assume that the bindings for Libfoobar are
ought to live in a module named Libfoobar.

Somehow, however, I'd find it tempting to use a longer, yet more
descriptive, Foo::Bar::Libfoobar; especially if there's a
related Foo::Bar module already on CPAN, and that Foo::Bar would
be the "proper" name for Libfoobar, should it be (re)implemented
as a native Perl library.

Perhaps there's anything else to consider?

TIA.

 

[George Mpouras]

Modules are kept physical as files in directories (simple eh
Perl search for modules at root directories of the @INC array. So

Foo::Bar::Libfoobar

means that there is a the following file

$an_INC_root_dir/Foo/Bar/Libfoobar.pm

 

[Rainer Weikusat]

I'm curious, what's the current preferred naming scheme for Perl
bindings to C libraries? Given such modules as GD or
Image::Magick, I'd assume that the bindings for Libfoobar are
ought to live in a module named Libfoobar.

Somehow, however, I'd find it tempting to use a longer, yet more
descriptive, Foo::Bar::Libfoobar; especially if there's a
related Foo::Bar module already on CPAN, and that Foo::Bar would
be the "proper" name for Libfoobar, should it be (re)implemented
as a native Perl library.

Perhaps there's anything else to consider?

First, I would drop the lib-prefix: If it is a standalone Perl module,
'we' already know that it is a library and putting lib in front of the
name is just keeping a convention of so dubious value alive that the
linker has actually contained code to work around it 'for ages'
(intepreting an argument a la -lbarfoo as request to link with a file
named libbarfoo). For the remaining part "it depends": Is 'foobar' an
'unstructured' term in its own right or is 'foo' something which
denotes a class of similar things with bar being a specimen belonging
to it? For the former case, it should be Foobar, integrated in a
suitable 'abstract top-level namespace' ie, Metasyntatic::Foobar, in
the latter case, it should become Foo::Bar.

 

[Ivan Shmakov]

First, I would drop the lib-prefix: If it is a standalone Perl
module, 'we' already know that it is a library

On the contrary, it's a module that provides a Perl interface
for a certain non-Perl library. The library is, however, called
both "the FOOBAR library" and "libfoobar" by the upstream.

Would that be a completely new and stand-alone module, I'd
indeed call it Foo::Bar (or, given that Foo::Bar is already on
CPAN, take some variation on it.)

[...]

For the remaining part "it depends": Is 'foobar' an 'unstructured'
term in its own right or is 'foo' something which denotes a class of
similar things with bar being a specimen belonging to it? For the
former case, it should be Foobar, integrated in a suitable 'abstract
top-level namespace' ie, Metasyntatic::Foobar, in the latter case, it
should become Foo::Bar.

As I've mentioned above, there already is a related Foo::Bar
module on CPAN, which, however, deals with a tiny subset of the
tasks related to Foo Bar. The scope of libfoobar I'm writing
Perl bindings for is considerably wider.

(... Or, rather, it's the Bar::Foo module, as in "FOOBAR," it's
Foo which is a specimen of Bar, not the other way around.)