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.
