Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Foo::Bar::Libfoobar vs. Libfoobar?

Reply
Thread Tools

Foo::Bar::Libfoobar vs. Libfoobar?

 
 
Ivan Shmakov
Guest
Posts: n/a
 
      07-21-2013
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.

--
FSF associate member #7257
 
Reply With Quote
 
 
 
 
George Mpouras
Guest
Posts: n/a
 
      07-22-2013
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
 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-22-2013
Ivan Shmakov <(E-Mail Removed)> writes:
> 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.

 
Reply With Quote
 
Ivan Shmakov
Guest
Posts: n/a
 
      07-22-2013
>>>>> Rainer Weikusat <(E-Mail Removed)> writes:
>>>>> Ivan Shmakov <(E-Mail Removed)> writes:


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


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

--
FSF associate member #7257
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
simple way to turn "foo and bar" to "+foo +bar" Max Williams Ruby 10 12-15-2007 09:02 AM
why functions in modules need 'global foo' for integer foo but not dictionary foo? seberino@spawar.navy.mil Python 3 07-29-2005 12:42 PM
Are foo[bar] = "" (at declaration) and memset (foo, '\0', bar) the same? Jonathan Bartlett C Programming 7 07-07-2005 11:46 PM
Regex combining /(foo|bar)/ slower than using foreach (/foo/,/bar/) ??? Gunnar Hjalmarsson Perl Misc 12 02-24-2005 08:46 PM
How to access Bar in Foo when Foo::Bar exists? Wejn Ruby 2 11-29-2003 03:21 PM



Advertisments