This is now on CPAN as Class::Data::Reloadable, same API as C::D::Inheritable.
d. On 9 Nov 2004 at 14:32, David R. Baird wrote: > > I've got this working now as a drop-in replacement for > Class::Data::Inheritable. Also now the working name is > Class::Data::Reloadable, which refers more to what it does and less > to how it does it. I'm not attracted by > Class::Data::Inheritable::Reloadable because that's just too much > verbiage, and anyway, it's not a subclass of CDI. Anyone have other > views on the name? > > On 7 Nov 2004 at 20:54, David Nicol wrote: > > > 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. > > > > I'm not too sure how this would relate to my module? The module only > persists class data within the lifetime of the currently running > process, but it allows you to retrieve class data for a class that > has been reloaded (deleted from %INC and require'd). I'd be > interested to hear of other scenarios where this would be useful, but > I think it's just a development support tool. > > Cheers, > > d. > > > > On 7 Nov 2004 at 12:40, David R. Baird wrote: > > > > > 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 > > > > > -- > Dr. David R. Baird > Riverside Content Management Systems > http://www.riverside-cms.co.uk -- Dr. David R. Baird Riverside Content Management Systems http://www.riverside-cms.co.uk
