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:41 PM, Sara Golemon <pollita@php.net> wrote: > 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...? > because I think that if we want to introduce this format, then we should do it "properly", eg. providing an easy-to-use method to decode such 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(). > >> 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. > are we talking about the SPLDoublyLinkedList's serialize format or the generic php serialize format? could you show an example? > > > 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" > if we introduce this option for the sole reason of making possible to unserialize this format, then I think my point about relevant 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. > sorry, it's one of my pet peeves > > > 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?) > That could work, what my point was, I would like to attack this problem as a whole and not by adding one-by-one changes. > > 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. > I would like to hear more people's opinions about this, but currently I'm on the side of the revert: it changes a widely used function to make it possible unserializing a rarely used deviant format with some additional efforts from the user, without any prior discussion or standard rfc process.. -- Ferenc Kovács @Tyr43l - http://tyrael.hu