Re: Naming convention for thin wrappers around C libfoo.so ?
On Tue, Dec 11, 2007 at 10:52:56AM -0600, Jonathan Rockway wrote: On Mon, 2007-12-10 at 23:29 +, Tim Bunce wrote: Re the choice of name for the low level library... Lib::Memcached Lib::memcached Lib::libmemcached My preference is for Lib::libmemcached because it emphasises the name of the library that it's a wrapper for. No shortage of opinions in this thread, but I thought I'd throw mine in anyway; Memcached::libmemcached. This name, to me, implies that it's a Memcached interface that uses libmemcached. It doesn't say raw or anything, but the lib part strongly implies that. YMMV JHMO :) You're right on both counts Jonathan... No shortage of opinions in this thread, and Memcached::libmemcached is a great name. Sold! Thanks Jonathan, and thanks to everyone who contributed. Tim.
Re: Naming convention for thin wrappers around C libfoo.so ?
On Tue, 11 Dec 2007 00:05:19 + Smylers [EMAIL PROTECTED] wrote: Or if you want Lib::, then Lib::memcached makes the most sense. Compare also to the C case: use Lib::memcached gcc ... -lmemcached The library's name is memcached; the fact it lives in a file called libmemcached.so is purely a convention of the environment; namely, dynamically linked ELF libraries. Similarly here, the fact it lives in the Lib:: namespace is a convention of the perl environment. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Naming convention for thin wrappers around C libfoo.so ?
On Tue, 2007-12-11 at 12:51 +, Paul LeoNerd Evans wrote: On Tue, 11 Dec 2007 00:05:19 + Smylers [EMAIL PROTECTED] wrote: Or if you want Lib::, then Lib::memcached makes the most sense. Compare also to the C case: use Lib::memcached Lib::Memcached Follows perl conventions more closely ... iirc, all lower case is for pragmas and such ... but there seem to be precedents both ways. gcc ... -lmemcached The library's name is memcached; the fact it lives in a file called libmemcached.so is purely a convention of the environment; namely, dynamically linked ELF libraries. Similarly here, the fact it lives in the Lib:: namespace is a convention of the perl environment. -- --gh
Re: Naming convention for thin wrappers around C libfoo.so ?
On Tue, 11 Dec 2007 08:04:04 -0500 Guy Hulbert [EMAIL PROTECTED] wrote: Lib::Memcached Follows perl conventions more closely ... iirc, all lower case is for pragmas and such ... but there seem to be precedents both ways. Ah yes, fair point. I was simply trying to argue against Lib::libmemcached, on the grounds of the 'lib' not really being part of the name. Yes; CamelCased names do seem the convention around here, except the pragmata, so I guess that's the way forward. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Naming convention for thin wrappers around C libfoo.so ?
brian d foy wrote: In article [EMAIL PROTECTED], Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: IMHO, Lib doesn't carry as much information as Raw or even API, given the already existing modules. Raw and API don't mean anything. Everything is an API :) Yes, everything is an API, but in a sense, everything is a library as well, depending on how you define that term. :-) I was proposing a name ending with API to follow the Win32 / Win23API scheme, the same way many modules now follow the name ending with X scheme for extension modules. It's not meaningful, but it seems to be the current convention. Lib denotes the external dependency, which says much more about the either two, which can refer to anything. There is (currently) no Lib:: module, while there are 78 distributions with API in their name. And if you check, most actually define low-level API to external things, for things ranging from system stuff (Win32 stuff, GSSAPI, card terminal stuff) to documents (PDF::API2), protocols (LDAP), and of course web sites (EVDB, Flickr, Facebook, Google). What I'm saying is just that there seems to be a pattern. Tim may or may not want to follow it. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Naming convention for thin wrappers around C libfoo.so ?
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.
Re: Naming convention for thin wrappers around C libfoo.so ?
Tim Bunce wrote: 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. Surely you found out about Cache::Memcached and friends? Basically what you're proposing is a refactoring of these. Are the current maintainers of same aware of your efforts? If so, perhaps they could hand over some namespace slots to you. So, here's the point: does anyone have any good objections to my establishing a new precident by using the Lib:: namespace for this? +1, imho it makes good sense to have (some future version of) Cache::Memcached depend on Lib::Memcached. -- Dominique
Re: Naming convention for thin wrappers around C libfoo.so ?
[[ This message was both posted and mailed: see the To, Cc, and Newsgroups headers for details. ]] In article [EMAIL PROTECTED], Tim Bunce [EMAIL PROTECTED] wrote: 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 tend to think that it depends on the library, so there isn't a best rule for everything. 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. For well known libraries that aren't going confuse a general case, I don't see a problem with a top-level namespace such as Memcached. 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? I'd prefer Lib:: to Cache::. As you say, Cache is a mess. -- brian d foy (one of many PAUSE admins), http://pause.perl.org archives at http://www.xray.mpe.mpg.de/mailing-lists/modules please send all messages back to [EMAIL PROTECTED]
Re: Naming convention for thin wrappers around C libfoo.so ?
On Mon, 2007-12-10 at 12:14 -0600, brian d foy wrote: I'd prefer Lib:: to Cache::. As you say, Cache is a mess. +1 Lib::Foo -1 Lib::libfoo -- --gh
Re: Naming convention for thin wrappers around C libfoo.so ?
On Dec 10, 2007 5:17 AM, Dominique Quatravaux [EMAIL PROTECTED] wrote: +1, imho it makes good sense to have (some future version of) Cache::Memcached depend on Lib::Memcached. me too
Re: Naming convention for thin wrappers around C libfoo.so ?
Tim Bunce wrote: 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. [...] 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 ...) I was wondering why you wanted to build yet another Memcached module given there is already Cache::Memcached::XS, but now I understand: you want to do something similar to what Paul Marquess did with Compress::Zlib when he splitted it between a high-level Perl frontend (Compress::Zlib) and a low-level driver (Compress::Raw::Zlib), which allowed him to provide bzip2 support (Compress::Raw::Bzip2). It's also similar to the Win32 situation: Win32API::* modules provide low-level API, while Win32::* provide high-level API. IMHO, Lib doesn't carry as much information as Raw or even API, given the already existing modules. So possible namespaces are: Cache::Raw::Memcached or CacheAPI::Memcached. Or, if you don't want to be related to the Cache:: namespace, Memcached::Raw or Memcached::API. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Naming convention for thin wrappers around C libfoo.so ?
On Mon, Dec 10, 2007 at 12:17:16PM +0100, Dominique Quatravaux wrote: Tim Bunce wrote: 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. Surely you found out about Cache::Memcached and friends? Basically what you're proposing is a refactoring of these. Are the current maintainers of same aware of your efforts? If so, perhaps they could hand over some namespace slots to you. It's not as simple as it may seem at first. Cache::Memcached is pure-perl. That's an advantage for some people. Cache::Memcached::XS is compiled but links to the libmemcache library (not the libmemcache*d* library that I'll be using). There is a need for a perl wrapper for the libmemcached library, but that doesn't invalidate the needs of others for other APIs. So, here's the point: does anyone have any good objections to my establishing a new precident by using the Lib:: namespace for this? +1, imho it makes good sense to have (some future version of) Cache::Memcached depend on Lib::Memcached. I'd rather say it makes good sense for the libmemcached library to be usable via multiple APIs, including an API compatible with Cache::Memcached, an API compatible with Cache, and an API compatible with Cache::Cache. Hence the two-level approach. Re the choice of name for the low level library... Lib::Memcached Lib::memcached Lib::libmemcached My preference is for Lib::libmemcached because it emphasises the name of the library that it's a wrapper for. (Think of libmemcached as a brand name. It's certainly distinct from memcached and even distinct from libmemcache.) I want people searching for libmemcached to also easily find Lib::libmemcached. My goal for this kind of thin wrapper is to be so thin that the documentation just defines a set of principles (type conversions etc) and then refers to the user to the documentation for the function in the underlying library. That's made easier in this case by libmemcached having a fairly well abstracted API. Tim.
Re: Naming convention for thin wrappers around C libfoo.so ?
On Mon, Dec 10, 2007 at 09:00:57PM +0100, Andreas J. Koenig wrote: On Mon, 10 Dec 2007 11:07:38 +, Tim Bunce [EMAIL PROTECTED] said: 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. But there is BRADFITZ/Cache-Memcached-1.24.tar.gz already?? libmemcached is (I'd guess) more than an order of magnitude faster than the pure-perl Cache::Memcached module. Also it's about to gain support for Consistent Hashing, which none of the other memcached APIs available from perl support. Tim.
Re: Naming convention for thin wrappers around C libfoo.so ?
Tim Bunce writes: Re the choice of name for the low level library... Lib::Memcached Lib::memcached Lib::libmemcached My preference is for Lib::libmemcached because it emphasises the name of the library that it's a wrapper for. (Think of libmemcached as a brand name. easily find Lib::libmemcached. Your proposed Lib:: namespace would be just for Perl modules which are thin wrappers around external compiled libraries -- which are all named libsomething. This would mean that every single module in the Lib:: namespace would start Lib::lib That seems redundant: either one of the libs in the name should be suffice. Or, to put it another way round, either Lib:: is intuitive enough that people know what it means (in which case the second lib isn't needed), or it isn't (in which case it isn't that useful as a name-space). ... I want people searching for libmemcached to also I think 'the set of all modues relating to caching' is more useful than 'the set of all modules that are thin wrappers around a library which was first implemented in a compiled language', so suggest Cache::libmemcached. Yes, Cache:: has some other modules in it you don't want to be associated with, but then so do most Cpan namespaces -- I'm sure you won't be tainted by them! Or if you want Lib::, then Lib::memcached makes the most sense. Smylers
Re: Naming convention for thin wrappers around C libfoo.so ?
On Mon, 10 Dec 2007 11:07:38 +, Tim Bunce [EMAIL PROTECTED] said: 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. But there is BRADFITZ/Cache-Memcached-1.24.tar.gz already?? -- andreas
Re: Naming convention for thin wrappers around C libfoo.so ?
Tim Bunce wrote: 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. Tim, I guess another question to ask would be are there other instances/projectsd where this sort of structure Lib::low-level-lib would be usefull for other projects. I would think so and agree with this approach. --Patrick -- Patrick Galbraith, Senior Programmer Grazr - Easy feed grazing and sharing http://www.grazr.com Satyam Eva Jayate - Truth Alone Triumphs Mundaka Upanishad
Re: Naming convention for thin wrappers around C libfoo.so ?
On Thursday 06 December 2007 23:11, 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 ??? Tim. Most people wrapping a library call it after what it does, hidding the fact that an existing library is used as implementation. That would eliminate anything with 'lib'. Which means that I'll go for '???' Cheers, Nadim.
Naming convention for thin wrappers around C libfoo.so ?
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 ??? Tim.
