Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.

The stdClass is a class which don't implement any interface on purpose
cause it has no behaviour. Whenever you cast to an (object) or use
json_decode() you get stdClass objects initially with no behaviour as well.

Thank you for your interest in PHP.

I think it's worth mentioning here that using JsonSerializable as a type hint makes very little sense. The JsonSerializable class is a bit of a misnomer, and should really be something like HasCustomJsonSerializationLogic. Your default assumption should be that *everything* is JSON serializable.

Yes, as I stated this is more of a feature request.

nikic@php.net
Not sure I get what you mean.
As I understood the point of this interface is to be able to decide if a given object van be serialized into json or not. And reason it has been added to PHP is that before everyone added the some into their projects by hand anyway.
If I define a method what will for example generate a json response by the given input I expect that the given input can be serialized hence I typehint them.
Otherwise it could be literally used with anything and would just generate an empty json object.
Serializable? For sure, but doesn't make much sense.
I agree that the name `HasCustomJsonSerializationLogic` you proposed would be better. Used something like that before JsonSerializable has been implemented in PHP

> Otherwise it could be literally used with anything and would just generate an empty json object.

The default JSON serialization behavior is to just serialize the properties. If you have a class

class Point {
    public int $x;
    public int $y;
    public int $z;
}

then the natural serialization for that is {"x": 0, "y": 1, "z": 2}, which is what you get by default -- you do need to and should not implement JsonSerializable in that case. You should treat any value under the assumption that it can be serialized (but check for encoding errors).

(In fact, a reasonable use of JsonSerializable would be to make the implementation throw unconditionally if your object is not serializable -- the fact that it implements JsonSerializable clearly doesn't indicate serializability in that case.)

I get that.
The thing is that in all the projects I saw in the past years, public properties are quite rare. Everything is hidden and can be only accessed via the defined methods