On Sat, Dec 08, 2007 at 06:38:50PM +0100, Sébastien Aperghis-Tramoni wrote:
Tim Bunce wrote:
If there's a libfoo.so and I want to create a perl module/distribution
that's just a very thin wrapper around libfoo, what should I call it?
LibFoo
Lib::Foo
Lib::foo
Lib::libfoo
libfoo
SomeCategory::Libfoo
???
Following the "Category::Foo" scheme:
[...]
Following the top-level namespace "Foo" scheme:
[...]
It's clear the "Category::Foo" scheme has the greater number of distributions.
It's also clear there's no firmly established best practice here.
I wanted to discuss the issue in the abstract first because the actual
library/module is in a category/namespace with it's own set of problems.
I'm looking to build a very thin wrapper around libmemcached
(http://tangent.org/552/libmemcached.html)
a high-performance feature-rich interface to memcached.
The natural category would be Cache:: but that namespace is a bit of a mess.
There are two big distributions (Cache and Cache::Cache) that have
different APIs. Each ships with a bunch of cache modules (Cache::Memory
vs Cache::MemoryCache). Then there are lots of other Cache::*
distributions and modules that may or may not conform to one or the
other API.
Since the extension I want to implement would not itself implement
either the Cache or Cache::Cache API I'm reluctant to put it into the
Cache:: namespace.
I was thinking in terms of a low-level 'thin' extension called
Lib::libmemcached with separate pure-perl modules implementing the Cache
and Cache::Cache interfaces.
So, here's the point: does anyone have any good objections to my
establishing a new precident by using the Lib:: namespace for this?
(Or perhaps CLib:: or SysLib:: or ...)
Or should I just add to the general mess in the Cache:: namespace?
Tim.
