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

From: Date: Wed, 23 Mar 2016 22:36:19 +0000
Subject: Bug #46600 [NoF->ReO]: "_empty_" key in objects (see #41504)
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-200069@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:         yohgaki@php.net
 Reported by:        Matt at mpcm dot com
 Summary:            "_empty_" key in objects (see #41504)
-Status:             No Feedback
+Status:             Re-Opened
 Type:               Bug
 Package:            JSON related
 Operating System:   *
-PHP Version:        5CVS, 6CVS (2008-11-18)
+PHP Version:        irrelevant
 Block user comment: N
 Private report:     N

 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------
[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.

------------------------------------------------------------------------
[2016-03-23 02:49:25] ofbeaton at gmail dot com

So I just ran into this problem while making a satis repository script for composer. I don't
see a good solution.

If I $composerJson = json_decode($composerJson, true) into associative arrays,
manipulate it, then json_encode($composerJson) then my 
  "require-dev": {}
turns into
  "require-dev": []
which composer chokes on. So obviously I can't read the composer file as associative arrays!
That isn't this bug, I just want to show upfront that using the associative array parameter on
my json_decode cannot solve my problem.

So I do: $composerJson = json_decode($composerJson, false) and turn it into objects
like this thread talks about. Except the most common composer.json contains something like this:
  "autoload": {
    "psr-4": {
      "": "src/"
    }
  }

it reads it in fine, but when I do json_encode($composerJson) again... I get:
  "autoload": {
    "psr-4": {
      "_empty_": "src/"
    }
  }

which composer then chokes on because of course "_empty_" has a different meaning than
"".

So I'm stuck doing a json_encode then using a hack, $composerJson =
str_replace('"_empty_":', '"":', $composerJson)
before writing it to file again.

The _empty_ key does not seem to me to be the right answer here. Should composer change the way
composer files for virtually all projects be written? Is this a composer bug?

Or should json_encode and json_decode objects reproduce a blank key?

I hope the answer is the later, but I cannot say for sure.

------------------------------------------------------------------------
[2016-01-25 14:56:31] ajf@php.net

This is arguably not a bug since you can't have objects with empty property names, so this is
necessary to allow decoding JSON objects with empty keys. However, that's a rather arbitrary
restriction. If we removed it, we could fix this.

------------------------------------------------------------------------
[2014-01-14 18:50:41] matt at mpcm dot com

Last post was a bad example, this is the actual output:
as object: {"_empty_":"c"}
as array: {"_empty_":"a","":"c"}

------------------------------------------------------------------------


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


Thread (24 messages)

« previous php.bugs (#200069) next »