idea - Class::Data::Separated
This is just an idea at the moment, and mainly I'm wondering if this kind of thing already exists? I'm debugging a mod_perl app just now, so I'm using Apache::Reload to allow me to edit modules and have them automatically reload without having to restart the server. Works very nicely, except when a module has associated class data. The data are all lost when the module reloads, so I end up having to restart the server after all. Partly I'm addressing this by refactoring some code out into modules that have no class data. The logical extension to this would be to provide a module that stores class data for other classes, so there's only ever one module that is really storing any class data. I'm thinking that a client module could set and retrieve its classdata into the helper class, which does a lookup based on the caller to locate the caller's class data, which it returns. Then I can safely mess with the code in the caller and not lose its class data. I generally use Class::Data::Inheritable to manage class data, and my first thought would be to base this thing on that, so it might be called Class::Data::Inheritable::Separated, or else just Class::Data::Separated. Is this wheel already spinning somewhere? Cheers, d. -- Dr. David R. Baird Riverside Content Management Systems http://www.riverside-cms.co.uk
PPMs for packages built with Module::Build
Dear Sir or Madam, It has recently come to my attention that ActiveState does not supply PPMs for CPAN modules that use Module::Build in their build process. I have received a support request for one of the CPAN modules that I maintain asking me not to have dependencies on modules that use Module::Build. This places me in an uncomfortable position. Why has ActiveState decided to isolate their ActivePerl users from a growing fraction of the CPAN? Is this a technical or business decision? If it's technical, would ActiveState like some help from the Perl community? Will there ever be PPMs for modules that use Module::Build? Why doesn't this issue appear in the ActivePerl bug tracker? Cheers, -J --
Re: Suite of modules to be released - the name game
John Siracusa wrote: There are a few things that make this difficult. The first is that any OO helper module depends on the object base class and method maker. The second is that the object base class and method maker are very simple, and hardly worth distributing separately. If they are very simple, why not use an existing module? What functionality do they add, why could it not be added to another accessor module? If it is because the others were too simple, could they have been split to load extra functionality on demand? You shouldn't answer these questions on this list btw. But they should help you decide whether to rip them out, or release them seperately. The third is that even the functional helper classes are very simple, and usually only exist so that I have a single point of access for some functionality within my suite. I suggest that you release them under the namespace of your own for now. However, over the next few years, you should actively try to move portions over to more functional namespaces and incorporate the functionality into other modules. This is a particularly more serious state of affairs for the database side of things; database libraries have more traps and pitfalls than you may be aware of, and the bugs in that space are usually the hardest to debug and have the worst impact! You should definitely ask on the POOP-group list about which existing DB library is most similar to your new approach. When you add a single method to a prepackaged module, could it be that the module could be enhanced with the feature? Try sending a patch to the author. Is your assessment of whether it fits in with the module you are using correct? Check with the community, maybe they have an approach that works in the way you want. Are you replicating the API of another module, with a competing implementation? That module should be released as Foo::Lite (if it is actually `Lite'r) or otherwise under the namespace of the original module. Once the great ideas and fresh approaches that you have discovered with your efforts are incorporated into other modules, or had new modules made from the ones that really are new and different, the originals can be deprecated and laid to rest. -- Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering)
Re: idea - Class::Data::Separated
what you describe soulnd like a more general case, which when solved, will solve the needs of the guy who wants persistent per-session database handles. -- David L Nicol How cool is that? -- Elgie
