Re: idea - Class::Data::Separated

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

• idea - Class::Data::Separated by David R. Baird
• Re: idea - Class::Data::Separated by David R. Baird
• Re: idea - Class::Data::Separated by David R. Baird
• Re: idea - Class::Data::Separated by David Nicol