Implement JsonSerializable for SplFixedArray

[nikic]

This returns an array for SplFixedArray JSON encoding, which
is more appropriate than an object with integer string keys.

Implements request https://bugs.php.net/bug.php?id=81112.

[Parsonswy]

This is I think more a question of convention. The JsonSerializable interface defines jsonSerialize() as having a mixed return type. Even though this implementation does only ever return an array, will it cause issues if someone wanted to extend SplFixedArray and override jsonSerialize() with a different return type like JsonSerializable?

I can't think of many situations where there would be a reason someone would have to do this, but I think if they were to be using this stub for intelisense it might complain that the child's method is incompatible with SplFixedArrays even though it should technically be allowed by the interface.

This is the deepest I've ever seen into PHPs internals so I don't know how else the stubs are used and whether running that hypothetical example would actually generate any errors.

[nikic]

Yes, a child class will not be allowed to widen the type. I guess if we really want we can declare this as a tentative type instead, so that any code hypothetically extending SplFixedArray with a different return type would not be immediately broken.

cc @kocsismate

[kocsismate]

Interesting problem.. Personally, I don't have many too much concern about the array return type (I'm not sure how common is to extend SplFixedArray + implement JsonSerializable), but if we want to be extra safe, a tentative return type seems like a good idea.

[Parsonswy]

For what it is worth, I am not overtly concerned either. I just saw it and wasn't sure if it was an overt decision to deviate from the interface.

[nikic]

I think I'll go with the explicit type here and change it to a tentative one if anyone complains that it broke their code :) It seems pretty unlikely to me.

[TysonAndre]

nit: Should this also update ext/spl/config.m4 and config.w32 to note the dependency on json now exists? E.g. those files already note the dependency on standard and this adds a dependency on a class defined in the json extension(module)

I'm not familiar with the reasons to include standard

https://github.com/php/php-src/pull/6655/files#r574432587

[nikic]

@TysonAndre I tried to figure out what PHP_ADD_EXTENSION_DEP would do for always required extensions. The module deps are important because they determine module startup order. Apparently PHP_ADD_EXTENSION_DEP should theoretically affect module registration order via internal_functions.c. It doesn't look like that actually works though (e.g. standard occurs after spl there), and I'm not sure under what circumstances registration order would matter either.

[nikic]

I tracked down what the issue is:

php-src/build/order_by_dep.awk

Line 14 in 5399489

cmd = "grep PHP_ADD_EXTENSION_DEP " module_dir "/config*.m4"

assumes that there is indentation before the PHP_ADD_EXTENSION_DEP call, which gets matched into $1. If it's not present all arguments get shifted by one and we get a nonsense dependency.

This is what happens when you try to program in unix tools.

[nikic]

I fixed the ordering script in be92a87 and added the json build dependency here, though I doubt it has any effect.