Introduce ELASTICA_JSON_UNESCAPED_UNICODE ELASTICA_JSON_UNESCAPED_SLASHES

[demon]

Avoids using the global defines from PHP. Follows up #559.

This lead to https://bugzilla.wikimedia.org/show_bug.cgi?id=65110 being filed downstream by myself. We use the existence of JSON_UNESCAPED_* defines to detect 5.3/5.4 behavior and handle fallbacks more gracefully. Elastica unconditionally defining these on 5.3 and below breaks our behavior detection.

Proposed PR should work on 5.3 as well as 5.4+

[demon]

Eh, not perfect yet. Emits some notices.

[ruflin]

That is a nasty one. To be honest I don't like the the usage / overwriting of the globals at all, but I don't see a better way at the moment. So in general it looks good.

Somehow it didn't trigger a travis build. Not sure why.

I assume your last comment means, some more changes are coming?

[demon]

Yes, I shall fix it up shortly, just hadn't finished it and got sucked into a bunch of meetings :)

[ruflin]

I thought about a better implementation. Instead of using the ugly constants I would suggest to introduce two static functions in Elastica\Util

Elastica\Util::getJsonUnescapedSlashes()
Elastica\Util::getJsonUnescapedUnicode()

These functions are called and deal with, if the constants are set or not. Like this we don't have duplicated code and no new global constants. What do you think?

[mal]

Given that these flags only feed json_encode, it might be nicer to wrap the functionality as a whole, avoiding both globals and slightly odd constant methods; i.e.

class Util { ...

    public static stringify($input)
    {
        return json_encode(
            $input,
            (defined('JSON_UNESCAPED_SLASHES') ? JSON_UNESCAPED_SLASHES : 64)
          | (defined('JSON_UNESCAPED_UNICODE') ? JSON_UNESCAPED_UNICODE : 256)
        );
    }
}

The example adds a method to Util, but it might be more intuitive to have a new Elastica\JSON class or something, so you can simply do JSON::stringify($array);. Thoughts?

[ruflin]

I like that it is obvious in the code that it is stringified to a json. With your additional mapper, that would be hidden a little bit. Because of this I like the JSON idea. Here I worry that we could get in conflicts with other JSON objects / mapper which probably exist. Not sure if we add too much complexity with an additional object if it only does one thing and is not used everywhere else where we deal with JSON.

@demon Your thoughts?

[demon]

I think doing it either of your ways is fine and avoids the global define problem entirely.

[demon]

Closing in favor of pull #614 instead.