Req #46600 [ReO->Csd]: "_empty_" key in objects (see #41504)

From: Date: Thu, 23 Jun 2016 19:14:07 +0000
Subject: Req #46600 [ReO->Csd]: "_empty_" key in objects (see #41504)
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-201815@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=46600&edit=1 ID: 46600 Updated by: bukka@php.net Reported by: Matt at mpcm dot com Summary: "_empty_" key in objects (see #41504) -Status: Re-Opened +Status: Closed Type: Feature/Change Request Package: JSON related Operating System: * PHP Version: irrelevant Assigned To: bukka Block user comment: N Private report: N Previous Comments: ------------------------------------------------------------------------ [2016-05-09 19:14:56] bukka@php.net Nikita has already sent a patch to allow empty property names in object. I will be happy to provide json part if that patch is merged. ------------------------------------------------------------------------ [2016-03-25 03:38:12] matt at mpcm dot com Yasuo, thank you for the response. Blank keys in json are a relatively common thing to encounter. I do agree, not all languages offer access to "", especially within traditional concept of a predefined class and named property. But... it feels like PHP should be able to handle this. Since we already have leading space properties working... I think the real fix (or feature request) for this bug, is that json_decode should not be returning stdClass at all. But something that extends stdClass, with a __get/__set to handle non-valid property strings that are valid json keys. Paired with undoing "" to "_empty_", this would essentially remove the issue entirely. Maybe that add's even more complications to php that I'm not considering ? Are there other keys that come to mind, or things that php also remaps, besides "" to "_empty_" ? I'll take a look at the newer php constructs this weekend, to see if there is an easier way around this now. I haven't looked into the issue recently, but in the past I used something like the below to allow object style access. https://gist.github.com/mpcm/2ce3687b121fdd13e2a8#file-jsonobject-class-php-L2 ------------------------------------------------------------------------ [2016-03-23 22:36:15] yohgaki@php.net I fully agree empty string is valid unicode string. The RFC does not mention validity of empty object property which is invalid in most languages. There is nothing we can do for this because object property name cannot be "". Any restrictions to property name apply as well for objects. However, we can cast object to array, array to object. [yohgaki@dev ~]$ php -n -r '$a = [""=>1]; $o = (object)$a; var_dump($o); $a = (array)$o; var_dump($a);' object(stdClass)#1 (1) { [""]=> int(1) } array(1) { [""]=> int(1) } It may be better to remove automatic "" -> "_empty_" conversion at some point. e.g. next minor release. ------------------------------------------------------------------------ [2016-03-23 12:17:38] matt at mpcm dot com Looking at that same doc: https://tools.ietf.org/html/rfc7159#section-1 "A string is a sequence of zero or more Unicode characters [UNICODE]." ------------------------------------------------------------------------ [2016-03-23 07:43:13] yohgaki@php.net Property names are defined as "string" and "string" is defined as follows. https://tools.ietf.org/html/rfc7159#section-7 string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF https://tools.ietf.org/html/rfc7159#section-4 Object property name should be unique. i.e. "The names within an object SHOULD be unique." I cannot tell if "" is valid or not. Is it valid JSON? BTW, the name for empty elements should be "__empty" or "__empty__" as we usually "__name" or "__name__" for reserved names. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=46600 -- Edit this bug report at https://bugs.php.net/bug.php?id=46600&edit=1

« previous php.bugs (#201815) next »