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
| From: | Ferenc Kovacs | Date: | Wed, 11 Jun 2014 13:01:15 +0000 |
| Subject: | 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 |
||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-74847@lists.php.net to get a copy of this message | ||
On Wed, Jun 11, 2014 at 2:05 PM, Julien Pauli <jpauli@php.net> wrote:
> 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
>
ok, I've just reverted it.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu