Re: Allow empty property names

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.ppv@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. >