in reply to Re: Safely altering the behaviour of heavily used modules
in thread Safely altering the behaviour of heavily used modules
After a huge amount of debate and discussions (see that link to RT) and some money slipped the way of an XS expert, this problem was solved, and solved both fully back-compatibly and in the best possible manner.
See "STORABLE_attach" in the Storable POD for details.
|
Re^3: Safely altering the behaviour of heavily used modules
by demerphq (Chancellor) on Apr 09, 2006 at 08:13 UTC
|
Regardless as to whether you added a new method. IMO Assignment to @_ should work as expected.
---
$world=~s/war/peace/g
| [reply] |
|
|
It can't ever work, because of the problem of references.
Storable supports circular references correctly, and the implementation of this means that what is in $_[0] may already have 4 or 5 other Perl references pointing to it by the time the hook gets called.
So if you were to replace $_[0] with $singleton, you would break all the other references.
If Perl references were purely heirachal, this wouldn't be a problem.
And that is why we have a seperate method. Because it provides an alternative that certifies that that class won't end up creating circular references below it, and thus that a modify/return type result will work sanely.
Read through bug #4901 and you might be able to understand it a bit more. It took me a long time.
| [reply] |
|
|
Im actually pretty familiar with this class of problems from working on Data::Dump::Streamer (whcih actually can and has to deal with much more complicated cases than Storable). In DDS I handle this by resolving the object first, then by resolving the copies of the ref. Thats why in a DDS dump youll often see stuff like 'V: $obj1->{foo}' which indicates that the value is a placeholder which will be replaced by a value of $obj1->{foo} when it has been completely defined. (You might also see 'A: $obj1->{foo}' meaning that the value is an alias of the named variable and not a copy of its value).
There is another aspect to this as well. To a certain extent its not Storables problem if a thaw method results in a breaking circular refs. Most time it wont be a problem and when it is its not Storables fault so I see no reason not to support the possibility.
So for instance in DDS its possible to make a freeze method that will make DDS go completely nuts. I dont view this as a problem for DDS as I see freeze/thaw semantics as being rope, and if people wish to use that rope to hang themselves thats their business.
Anyway, its sounds to me like Storable has somehow painted itself into a corner and that this problem is harder to deal with because of it. And it makes me all the more glad that I didnt copy the storable freeze/thaw interface in DDS.
---
$world=~s/war/peace/g
| [reply]
[d/l] |