Move Json utility class into Drupal\Component\Serialization

1: json.1.patch queued for re-testing.

1: json.1.patch queued for re-testing.

1: json.1.patch queued for re-testing.

1: json.1.patch queued for re-testing.

1: json.1.patch queued for re-testing.

I just don't see why this particular code is specific to drupal.

The only code that exists in this class is this:

    return json_encode($variable, JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_AMP | JSON_HEX_QUOT);

All of these flags are native PHP constants:

http://www.php.net/manual/en/function.json-encode.php
http://www.php.net/manual/en/json.constants.php

This code is specific to Drupal, because the one and only purpose is to harmonize and standardize JSON-encoded strings throughout Drupal modules.

If I'd need to encode variables into JSON in my own non-Drupal component/project/code, then I assure you that I won't use a utility helper class from Drupal to do that, because that would be a totally senseless dependency — json_encode() is readily available.

Other projects (like drupal people writing php only projects) could profit.

Profit from what?

1: json.1.patch queued for re-testing.

Hm. Perhaps we're talking past each other?

Are you saying that you'd be fine if the class was moved into Drupal\Component\Serialization instead of Drupal\Core?

The reason for why I'm suggesting Drupal\Core\Serialization is that all of the serialization classes are hard-coding various flags that are, in essence, just simply no more and no less than Drupal's preferences; i.e.,

1. This Json class hard-codes some json_encode() flags, because we expect most JSON to get rendered on an HTML page.
2. The Yaml class hard-codes flags for Yaml\Dumper to comply with Drupal coding standards; i.e., indent 2 spaces instead of 4, and don't switch to inline YAML after a certain nesting level.
3. Only the PhpSerialize class hard-codes nothing, because PHP serialize() does not support any flags.

I assume the point where we digress is that

1. You're saying that the concept of a standardized serialization class toolset could be useful for others.
2. I'm saying that the concept might be, but the actual implementations are not, because the implementations are hard-coding assumptions that are special to Drupal.

In order to make the concept a truly useful standalone component, we'd have to abstract the hard-coded assumptions, bloat the whole shebang with a serialization manager/configurator service and/or other ways to e.g. pass or statically set the configuration... The end result of such an effort would be something along the lines of Symfony's Serialization component, which is a super-complex beast of code.

However, if it's really just the Component vs. Core aspect, and if my arguments are not able to convince you, then I'm happy to concede and simply move the serialization classes into Drupal\Component\Serialization — I personally think that it does not make sense, but I really want/need to move forward on this.

Moved PHPUnit test accordingly.

Updated all new instances after #2093173: Remove all calls to drupal_json_decode(), use \Drupal\Component\Utility\Json::decode()

Hah. HEAD is moving fast today. ;)

30: json.30.patch queued for re-testing.

36: json.36.patch queued for re-testing.

Patch still applies cleanly (despite the high core commit volume these days).

Merged 8.x.

After further discussion on #2208633: Add a Yaml class to Drupal\Component\Serialization + IRC...:

Moved Drupal\Core\Serialization into Drupal\Component\Serialization.

Updating issue summary accordingly.

Haha + issue title :)

diff context conflict

diff context conflict

Merged 8.x

Manually merged, verified, and confirmed the re-roll.