An $options parameter after $index in Json::get() and all its variants (i.e. Json::getAs*()) and an option in either JsonOpt or a new GetOpt class should be added, which:

• GetOpt::STRICT: Throws an exception when the index does not exists.

This is the only option for now, but it may be added more options later.

When a bad index (e.g. an index as an array) passed to a method, instead of checking it to be either a string or an integer, a TypeError is thrown. Instead, a custom exception should be thrown.

It is a performance-cost operation, every time it gets executed. A replacement for this should be considered. One suggestion is handling by-method when accessing data, and checking inside every method; however, it's a bit hard to implement.

The reason of so is calling Json::exchange() from child classes that extends Json class. The constructor of the child class might be completely different.

Sometimes, it's useful to get the parent array by-reference, e.g. for unsetting some keys, in Json::forEachRecursive(). Pass a third argument to the callable for this.

Removing the return types of Json::*Option*() methods (e.g. Json::setOptions()) causes extending the class to be easier, because of redeclaring these methods in the child class will be more suitable. Currently, sometimes it causes incompatibility with the parent class. Instead of setting return value type hint to self, it should be commented.

Currently, it's only possible to pass a string or an integer as index in the methods. However, it's a good idea to allow arrays to be passed (but not objects, because of its overhead). In this case, all array elements must be checked to be either a string or an integer. A possible improve in this case would be directly passing the array to Json::findElementRecursive() without checking it and iterating it twice in Json::extractIndex().

Depth will tell the method to call the closure on which arrays. The default depth should be 0, and it should be counted from inside of the data.

Using of child class methods after calling a parent class method using fluent interface is a bit bad. For example:

class Json2 extends MAChitgarha\Component\Json
{
    public function copy() {}
}

$json = new Json2();
$json->set([""])->copy();

Calling Json2::copy() after Json::set() is valid, but IDEs will not show it because of the self return type. Using static would fix this issue.

Add PHP's JSON_* constants to the class, and make the possibility to add or remove them. For example, add the options before calling Json::getAsJson(), instead of passing options as arguments.

The methods will create a new Json instance, one using array keys, another from array values. Also, the value passed to them may be an object, but it must not be scalar.

DocComment of Json::do() says that the callable gets four arguments. It is wrong. It accepts three arguments, and the second one must be removed.

Just like #55, and because of that reason.

Currently, flexibility to do custom operations on the data is enough:

1. Extending Json class and add some custom methods to it;
2. Using anonymous classes to define methods on-the-fly;
3. Using Json::do() method.

However, it would be a good feature to add some methods on the fly, like the following:

$json = new MAChitgarha\Component\Json();

$json->customMethod = function ($args) {
    // Doing something interesting here
};
$json->customMethod("arg", "uments");

Things to note:

1. The on-the-fly method definition uses __set() to set a new method, and calling a defined method uses __call().
2. Defining static methods is hard to implement, so it should be ignored. However, it should be considered.
3. Trying to override an existing class method must try an exception (or error), and trying to call a non-existence method should try an error (i.e. should not be an exception).
4. It should be a way of accessing other methods inside the closure. The instance of the class may be passed through an argument to the closure, or it may be bound inside the closure.
5. It should be a way of accessing an element in data using an index. The element should be extracted and be passed as an argument to the closure.

Calling other methods inside Json class from the callable of Json::do() should be considered. Currently, it is now possible to do that. As an example:

$json = new Json();

$json->do(function () use ($json) {
    // $json->something();
});

However, this could be improved; maybe using Closure::bind() or Closure::bindTo(). Also, undefined behaviours might happen:

$json = new Json([
    "something" => 10
]);

$json->do(function (&$value) use ($json) {
    // Change data completely, set it to a string
    $json->set("Something");

    // Nothing happens here!
    $value = 3;
}, "something");

I don't know if it is fault of PHP itself or Json class, however, this behaviour must be considered.