On Tue, Sep 3, 2024 at 2:27 PM Philip Hofstetter <phofstet...@sensational.ch> wrote:
> Hello, > > As per my previous email to the list, I have now created the official RFC > to deprecate calling json_serialize() on instances of classes marked with > ZEND_ACC_NOT_SERIALIZABLE. > > https://wiki.php.net/rfc/deprecate-json_encode-nonserializable > > > Sharing my experience, I never use json_encode on objects but on arrays (that are both JSON objects or JSON arrays). When I see an object implementing JsonSerializable, I think it is the wrong approach, and I am usually able to find a better way. Maybe if we could go back in time, we would not allow json_encode on an object, except if it implemented JsonSerializable, but that ship sailed long ago. To your proposal, I think the BC break would be pretty big and I don't see a way it would pass. On https://www.php.net/json_encode we can read: > If a value to be serialized is an object, then by default only publicly visible properties will be included. So that's the expected behaviour. Yes, you can say that encoding as JSON is just "another serialization method", but the default method in PHP, using json_encode()/json_decode(), is not symmetrical when using objects. And here lies the difference with serialize()/unserialize(), as this one aims to be symmetrical, and where it can't be, it has a way to stop the serialization. I am happy with the current way it works, getting an empty JSON object if there are no public properties for a Generator or Closure. And I don't think having an error for them would improve the language in a meaningful way, and the BC break is not worth it. Regards, Alex
