Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91955
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKws9z2iMp33XmFZdshAgWX07J3Yh41cDV73CyEBh2pOceNFkg@mail.gmail.com>
References: <CAF+90c_Qi6=iQK=wjCBUreMmt9KiUyh3bZfn_roTJDEC-++EBg@mail.gmail.com>
 <CAKws9z2iMp33XmFZdshAgWX07J3Yh41cDV73CyEBh2pOceNFkg@mail.gmail.com>
Date: Fri, 25 Mar 2016 21:31:50 +0100
Message-ID: <CADyq6sLdsT2k=L-ZYEZUP7N4uSFvUday21wkN2kSzPFePo3Row@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114013240dd5eb052ee57515
Subject: Re: [PHP-DEV] Allow empty property names
From: ocramius@gmail.com (Marco Pivetta)

--001a114013240dd5eb052ee57515
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 25 March 2016 at 21:19, Scott Arciszewski <scott@paragonie.com> wrote:

> On Fri, Mar 25, 2016 at 1:45 PM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
> > Hi internals,
> >
> > Currently we do not allow (*) creating empty property names on objects,
> > i.e.
> >
> >     $obj->{''} =3D 42;
> >
> > is illegal. While empty property names are unlikely to be useful per se=
,
> > they are problematic for deserialization of foreign formats like JSON. =
To
> > avoid this issue {"": null} will currently decode to a property named
> > "_empty_" rather than "". Notably, this means that JSON decode and enco=
de
> > do not round-trip (as we do not convert _empty_ back to an empty name
> while
> > encoding).
> >
> > There is no technical reason (that I can see) for keeping this arbitrar=
y
> > restriction. I believe that the original reason for the restriction was
> our
> > use of NUL-prefixed property names for name mangling, combined with the
> > fact that an empty string at the C level happens to "start" with a NUL
> > byte.
> >
> > A patch to drop the restriction and allow empty property names:
> > https://github.com/php/php-src/pull/1836 It does not touch the JSON
> > handling, as there are BC concerns involved there, I leave that to the
> > ext/json maintainer.
> >
> > Any objections to changing this?
> >
> > Regards,
> > Nikita
> >
> > (*) There are roundabout ways to create them anyway.
> >
>
> =E2=80=8BCurrently, this succeeds:
>
> $x =3D json_decode('{"_empty_": "no", "": "foo"}', true);
>
> While this does not:
>
> $x =3D json_decode('{"_empty_": "no", "": "foo"}');
>
> =E2=80=8Bhttps://3v4l.org/FJHVV
> =E2=80=8Bhttps://3v4l.org/15Sfm=E2=80=8B
>
> I'm personally 50/50 on it. =E2=80=8BI think allowing an empty property i=
s kind of
> weird, but not the weirdest behavior PHP allows. Overall, it might
> (ironically enough!) make working with JSON _more_ consistent, and probab=
ly
> have other benefits that I can't even imagine at the moment.
>

Note that also that these ones won't work at the moment:

var_dump((object) ['' =3D> 'foo']);
var_dump((object) ["\0*\0" =3D> 'foo']);
var_dump((object) ["\0Foo\0" =3D> 'foo']);

Seems to work consistently on HHVM though: https://3v4l.org/7MO7E

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--001a114013240dd5eb052ee57515--