adamk has asked for the wisdom of the Perl Monks concerning the following question:
I've just started using Storable heavily for the first time, to implement server-abstracted storable SQL queries. By heavily I mean I need to play a lot of games with STORABLE_freeze/thaw hooks to let some fairly complex internal structures store correctly.
Now unfortunately STORABLE_thaw, rather than just giving you the class name to create an object of, "helpfully" creates an empty (and of course invalid) "object", which it expects you to fill and correct so that it becomes a valid object.
It also runs in void context, and returns via the passed argument, which isn't very Perlish at all.
Unfortunately, this "helpfulness" makes STORABLE_thaw completely useless for things like Singletons or classes with pools of objects, since you can't correct the link to refer to the Singleton (you are just left with an empty, invalid and broken object).
There are a number of bugs in rt.cpan.org relating to this problem, and I've taken it on myself to resolve the problem, as it is hurting me badly. I've defined the new behaviour I think STORABLE_thaw should have as
1. STORABLE_thaw called in scalar rather than void context
2. If and only if STORABLE_thaw returns a _different_ object from the empty one passed in, that also isa() in the same package, use THAT object in the thawed version instead.
This change is functionally back-compatible, but will this break anything? Using File::Find::Rule::PPI to find every STORABLE_thaw subroutine in a minicpan checkout, I found that 2/3rds of them do either "return self;" or "return;" for safety sake and will thus act sanely, and the rest don't appear to be able to race easily (I've filed rt.cpan.org bugs against them detailing the one line change just in case).
After that long intro, my question is... "Is there anything else I can do to ensure a clean changeover to the new behaviour, assuming I can convince the Storable maintainers to accept the patch."
Update
See http://rt.cpan.org/NoAuth/Bug.html?id=4901 for ongoing progress of the proposal to change STORABLE_thaw
Now unfortunately STORABLE_thaw, rather than just giving you the class name to create an object of, "helpfully" creates an empty (and of course invalid) "object", which it expects you to fill and correct so that it becomes a valid object.
It also runs in void context, and returns via the passed argument, which isn't very Perlish at all.
Unfortunately, this "helpfulness" makes STORABLE_thaw completely useless for things like Singletons or classes with pools of objects, since you can't correct the link to refer to the Singleton (you are just left with an empty, invalid and broken object).
There are a number of bugs in rt.cpan.org relating to this problem, and I've taken it on myself to resolve the problem, as it is hurting me badly. I've defined the new behaviour I think STORABLE_thaw should have as
1. STORABLE_thaw called in scalar rather than void context
2. If and only if STORABLE_thaw returns a _different_ object from the empty one passed in, that also isa() in the same package, use THAT object in the thawed version instead.
This change is functionally back-compatible, but will this break anything? Using File::Find::Rule::PPI to find every STORABLE_thaw subroutine in a minicpan checkout, I found that 2/3rds of them do either "return self;" or "return;" for safety sake and will thus act sanely, and the rest don't appear to be able to race easily (I've filed rt.cpan.org bugs against them detailing the one line change just in case).
After that long intro, my question is... "Is there anything else I can do to ensure a clean changeover to the new behaviour, assuming I can convince the Storable maintainers to accept the patch."
Update
See http://rt.cpan.org/NoAuth/Bug.html?id=4901 for ongoing progress of the proposal to change STORABLE_thaw
Back to
Seekers of Perl Wisdom