Hi,
I have been thinking about it and I would be ok with removing _empty_ in
7.1. That inconsistency is quite annoying and I never liked it. If we can
rid of it, that would be great! I realise the BC concern but I see that
more as a limitation and inconsistency between array and object decoding.
It's more an edge case anyway so I don't think there should be a big
concern. I think that it makes sense to hear if anyone would be against it
in json but I think that the limitation could go away already as it has
been discussed more than a month ago and I don't see any real objections.
@Nikita: if you merge it, I will be happy to create a PR for json...
Cheers
Jakub
On Fri, Mar 25, 2016 at 5:45 PM, Nikita Popov <nikita....@gmail.com> wrote:
> Hi internals,
>
> Currently we do not allow (*) creating empty property names on objects,
> i.e.
>
> $obj->{''} = 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 encode
> 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 arbitrary
> 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.
>
