Storable singletons

I'm in the middle of designing support for serializing singletons with Storable in Class::InsideOut -- which will be the last feature before 1.0.

I could benefit greatly by hearing some examples and opinions for any or all of these questions:

How do you use singleton objects currently?
Do you serialize them? If so, how?
When thawing, if no singleton has yet been created, how do you regenerate the singleton from frozen values?
If a thawed singleton "conflicts" with an existing singleton, how do you resolve that conflict?

References to specific modules or applications where I could see code would be very useful, too.

For those who don't understand why serializing singletons is a tricky proposition with Storable, it revolves around the necessary limitations of the STORABLE_attach hook. Here are a few references about it here and on RT:

Advice and insights on this topic would be greatly appreciated.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Comment on Storable singletons Select or Download Code

Replies are listed 'Best First'.
Re: Storable singletons by hv (Prior) on Apr 09, 2006 at 03:26 UTC
In my work application there are 3 singleton classes. The first is the CGI object, which inherits from the (non-singleton) 'site' object (the configuration of this installation of the app), and adds to it the CGI-specific I/O capabilities. It is created at BEGIN time and stored in a lexical variable at the package scope to ensure its singularity. The second is the logging object, which captures most stderr output and splits it to a per-script, per-site logfile. It is created when needed (though at BEGIN time in the case of a CGI invocation), and stored in a lexical variable at the package scope to ensure its singularity. Arguably it should not be - certain scripts need to deal with information from multiple sites - but I haven't yet worked out what correct behaviour really is in such cases, and current behaviour hasn't proved a problem to date. The third is arguably not a singleton: it is the database class that mediates access to the 'site' table, containing the client-modifiable configuration options. This uses our base database abstraction layer, but overrides the insert/delete mechanisms to ensure that the given site has only one entry in the table. None of these are serialised per se, except in the sense that the fields of the last one are serialised to store them in the database. Hope this is of some use as a data point, Hugo	[reply]
Re: Storable singletons by demerphq (Chancellor) on Apr 09, 2006 at 11:30 UTC
Will Class::InsideOut support Data::Dump::Streamer? The Freeze/Thaw support there was a direct response to your earlier nodes on this subject so I'm hoping so... ;-) --- $world=~s/war/peace/g	[reply]
Re^2: Storable singletons by xdg (Monsignor) on Apr 09, 2006 at 13:03 UTC
Yes, it will, unless something pops up during implementation (which I doubt). However I'm targeting that for after the 1.0 release. The 1.0 release is simply going to mark where I think that the API and basic operations are stable. `Storable` singletons might wind up changing the API, and that's been the major holdup for my feeling comfortable declaring the API ready. In the `Todo` file in my development branch, `Data::Dump::Streamer` support was already first on the post 1.0 list, followed by adding more accessor styles and then refactoring the documentation a bit. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply] [d/l] [select]