Re: Re: com php-src: Add optional second arg to unserialize(): ext/standard/basic_functions.c
ext/standard/tests/serialize/serialization_error_001.phpt ext/standard/tests/serialize/unserialize_consumed.phpt ext/standard/var.c

On Tue, Jun 10, 2014 at 7:02 PM, Sara Golemon <pollita@php.net> wrote: > SPLDoublyLinkedList's format was just the original wtf moment which > caught my attention. I went with the change to unserialize() because > that gives more power to the user. If you don't like that simple > approach, we could always introduce a new construct entirely, say > something like the following (note that I haven't given deep thought > to this API, it's just off the cuff): > > class PhpUnserializer { > public function __construct(string $str): void; > > /* advanced APIs for this kind of case */ > public function isValid(): bool; // whole string was parsable serialize > data > public function getErrorOffset(): int; // Where unserialize stopped > parsing > > /* Basic APIs for common cases */ > public static function unserialize(string $str): mixed; > public function isScalar(): bool; > public function size(): int; > > /* Maybe implement Iterator in some clever way to avoid unserializing > * the entire string at once? */ > > /* Override in child class for autoload/filter classes as they're > implemented */ > public function getClass(string $class, mixed $data): ?object { > /* Base implementation instantiates $class and unserializes it with > $data > * Children could add logic like: > * if ($class != 'stdClass') throw new Exception("Eff Off"); > * else return parent::getObject($class, $data); > */ > } > } > I think that this change would "legalize" this custom serialize format instead of keeping it as an implementation detail of SPLDoublyLinkedList but it would still require the user to write the boilerplate to parse these kind of data., I would like to hear why did you wanted to be able to unserialize this format, instead of using SPLDoublyLinkedList's->unserialize, because atm. I fail to see that this would be a common enough scenario which would warrant the addition to unserialize(). Personally I don't like that we have expose these separate similar but still different serialize format (serialize(), the serialize format by session_encode() which also omits the wrapper block, and now I learned about SplDoublyLinkedList. (And session_encode/decode is even more pita because it only allows encoding from/decoding to a superglobal, so if you wanna parse arbitrary sessions, you can't do it without global side effects) So I think instead of introducing small one-by-one changes like this, we should maybe rethink our current approach of serializing/unserializing arbitrary data and provide/expose some easy to use tools to encode/decode the wide variety of formats used in php. -- Ferenc Kovács @Tyr43l - http://tyrael.hu