Re: Safely altering the behaviour of heavily used modules

You have probably done this already, but it would be useful to add tests for both the new behavior situation and the old default. Check objects returned for both cases, which is something that may not be done in the current test suite. Check that freezing and thawing close the loop in both cases. I'm not sure what race easily means, but I am sure that you will have to deal with it in your proposal.

Add documentation describing changes and give example code where the new behavior may be useful.

-Mark

Comment on Re: Safely altering the behaviour of heavily used modules

Replies are listed 'Best First'.
Re^2: Safely altering the behaviour of heavily used modules by adamk (Chaplain) on Mar 09, 2005 at 02:59 UTC
Well, by "race easily" I mean for example that some uses of STORABLE_thaw are something like... `sub STORABLE_thaw { my ($self, $string, @refs) = @_; ... %$self = %rebuilt_contents; }` [download] Now, if called in scalar context, that should return the number of elements in the listified hash, which won't be a problem. But it's only safe accidentally, not by design. The original author was told that anything that might be returned would be ignored. But there is the potential for one of these cases where the function doesn't have an explicit "return;" to accidentally return a different object of the same class, which the new behaviour would interpret as an alternate object and treat incorrectly.	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: Safely altering the behaviour of heavily used modules
by adamk (Chaplain) on Mar 09, 2005 at 02:59 UTC

sub STORABLE_thaw {
    my ($self, $string, @refs) = @_;

    ...

    %$self = %rebuilt_contents;
}
[download]

[reply]
[d/l]