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 Wed, Jun 11, 2014 at 9:36 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > > > 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. Same for me. Serialization could also be an interesting topic for PHP-Next. Julien Pauli