Front page | perl.perl5.porters |
Postings from April 2016
My sincere apologies for the very long delay in this reply. Ben Bullock via RT <perlbug-followup@perl.org> wrote: > As bulk88 points out in his very informative post there are a number of different ways of making an object, but the method using IVs as described here: > > http://www.lemoda.net/perl/perl-xs-object/index.html > > will inevitably lead to errors of this kind. Unless you can demonstrate that the above method of blessing a T_PTROBJ is illegal somehow according to the Perl specifications it seems to me that Storable should not be doing what it is doing. For the record, I certainly don't think that T_PTROBJ and related implementation techniques are invalid or inappropriate. > The part which causes the segmentation fault is blessing the copy of the object into the class JSON::XS within Storable rather than the breaking encapsulation part, so I would suggest either not blessing objects into classes or giving the user responsibility for object serialization as described above. The method I described at the top, of making "secret" objects hidden behind a hash of random keys could just as easily be applied to a pure Perl module which would break Storable in a similar way, although without the segmentation fault errors. This could certainly be made to work. However, I don't think it's possible to change Storable's default behaviour here. Most Perl classes are simple blessed hash refs, with all their data readily visible to Storable; and users therefore expect to be able to use Storable to store and retrieve such objects today, without doing anything special. Changing this would certainly break large parts of Storable's test suite, and my very strong expectation is that it would also break large amounts of extant code that uses Storable. Storable does already call classes' STORABLE_freeze and STORABLE_thaw hooks when they're available (which I think counts as "giving the user responsibility for object serialization" as you suggest). Would your needs be met by giving Storable an option to have it refuse to serialise and deserialise blessed references for classes without such hooks? This would at least let code calling Storable opt in to enforced delegation of responsibility for serialisation and deserialisation. -- Aaron Crane ** http://aaroncrane.co.uk/Thread Previous | Thread Next