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 10:29 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > On Tue, Jun 10, 2014 at 7:02 PM, Sara Golemon <pollita@php.net> wrote: > 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., > And that's a problem because...? > 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(). >> SPLDoublyLinkedList's format was just the original wtf moment which >> caught my attention. "just the original wtf", I went looking around github and elsewhere and found other cases of serialize data being embedded in other payloads (which included hacks to make it easier to cut the serialize data out in order to unserialize it. By providing more powerful tools to the application, fewer hacks become necessary. > 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. > I don't either. But that issue is orthogonal to whether or not unserialize() provides an optional output parameter which says "btw, I stopped trying to parse here" > (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) > Again, clowny, but unrelated to the topic at hand. > 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. > See also: the classes (classes, really, since PhpSerialize would be an obvious complement) I suggested, or some variation there on. Perhaps a registry of some kind which would include the aforementioned formats plus json and whatever else (dson for the luls?) I do want to stress that were wandering into the weeds a bit though. On the central question of this parameter on this function: If you feel strongly, revert it. You won't hurt my feelings. -Sara