Jay Lawrence wrote: > At this point I am agonizing over what to call it and how to package it. > ... > Some modules can stand on their own, some depend on others.
Any module which can be used independently -- and which you reasonably expect someone *would* use independently of your system -- should be named independently. There's no reason you can't release a module Bar which happens to depend on some other module Foo which was also by you. The Bar bundle could include Foo, for convenience, but you may also want to upload Foo separately. > Should I consider a name like Apache::Session::Lite? What about > Session::Lite because it doesn't really have anything to do with Apache > at all (Other than it is a good place to use it). I hope you think you've answered your own question. :-) Unless it's Apache-specific, don't name it so. > What about my persistent object environment. ... > Do I add this to Class::*? Or do I go the route of POE and create > yet another top level name? Hard to say without more info. Probably we'll need to discuss (some of) your various modules specifically. > Some guidance in the area would be most gratefully appreciated. One general guideline is that standalone frameworks can reasonably get their own top-level name. Modules should be named by what they do. And since, with good software engineering, modules are made to have low cohesion, what they do is as independent as possible from the frameworks/applications in which they're used. So, you may have a framework with a top-level name Foo, but bundle with it numerous other modules which are *not* under Foo::. hth, -- John Douglas Porter
