Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93113 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13322 invoked from network); 8 May 2016 15:04:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 May 2016 15:04:22 -0000 Authentication-Results: pb1.pair.com smtp.mail=jakub.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=jakub.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.44 as permitted sender) X-PHP-List-Original-Sender: jakub.php@gmail.com X-Host-Fingerprint: 209.85.213.44 mail-vk0-f44.google.com Received: from [209.85.213.44] ([209.85.213.44:36227] helo=mail-vk0-f44.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6B/01-04420-5755F275 for ; Sun, 08 May 2016 11:04:22 -0400 Received: by mail-vk0-f44.google.com with SMTP id s184so40518196vkb.3 for ; Sun, 08 May 2016 08:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+uS5TQrvA/kD1fMcWjdMu85c+DZM8puIPktjPNex4fo=; b=aDpOwikofpPLEyvYpTR4LHPAiAijFrdmmOqc0++4HaOe+vJEjXS016Z6603ish0BwZ DRKTrWv6MpzufePQuDm2ASU9i6JL/92CrKsqvRyY0MDSc2mRqeM8y9TKW6y7YLvFhNux ZhqeJ3zZXov1LLZD90Td8yV44cyZg11sXtXOsGbdKhc6LlOmN9+Gt5Lu+GpPEhrJL5q8 bIrRbyHb9o28jnz8iPDyvR5Cm5jb5Qisv4yly1klBObNWmIJGsgsz8+Q4WAvQbVsVcPN usDFWodTM6H2+sY4LFOI1VSns3F0Xb0/v/VdunzJRDiIaEtyKIjbKbBeyY1I43dyhSUI /jlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+uS5TQrvA/kD1fMcWjdMu85c+DZM8puIPktjPNex4fo=; b=TBYYupVkP0E7BM+AZ+MicGGfV8CiKD+gkJv0i3Mpl1fCPTxxRTuch2hkUsgKAMzJrI JzKGnG2hLmOcE0hVXk6p2ZU8+VgICZx6k6R2tELYYf1dqC/+4J+OyCiMrvuIPgQprosF VUqTDfdLOp+/CyJazJYzq13HxzFnnIInoFM6PAnbDSB+ap/BXcPYVn0ZvssKIhzpe1nZ iLhOYC/eQvEJzNa5eB8A9sh5xHSweo+Mw6khyuvA74PjbM5+sasRZK13FfLJZ9rBMQhE Kx86M2yvrxhz7VGX7rhWAmXxQiASjjRkDxDLMg1EoP9/AfMCFbDNzn8puMtdBcFCwFUd Zv4g== X-Gm-Message-State: AOPr4FXDjRMh3oMJnn2wE8mne/q0HqBqBwEeUTP4hefRtF3gyOWxPOGxt6MCt1D7N56teWG9LycwW5k8VZzjTg== MIME-Version: 1.0 X-Received: by 10.159.35.35 with SMTP id 32mr18365641uae.31.1462719858898; Sun, 08 May 2016 08:04:18 -0700 (PDT) Sender: jakub.php@gmail.com Received: by 10.31.180.8 with HTTP; Sun, 8 May 2016 08:04:18 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 May 2016 16:04:18 +0100 X-Google-Sender-Auth: Q2zyPq5Z-qhrdQYzQNQ1taCfMtM Message-ID: To: Nikita Popov Cc: PHP internals Content-Type: multipart/alternative; boundary=001a113ce32898823e05325601ca Subject: Re: [PHP-DEV] Allow empty property names From: bukka@php.net (Jakub Zelenka) --001a113ce32898823e05325601ca Content-Type: text/plain; charset=UTF-8 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 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. > --001a113ce32898823e05325601ca--