> I don't think any of the discussion points mentioned above is resolved
I believe that most of the discussion points mentioned have been addressed and resolved. Regarding the concern that an array cast is the only operation capable of exposing object state, the same functionality can be achieved with reflection - as demonstrated here: https://3v4l.org/Dh3PO <https://3v4l.org/Dh3PO>. > a heavy BC break on the `(array)` cast instead of introducing a clear > `SomeArrayableInterfaceType#toArray()` (to be explicitly called) is a no-go > from my end As far as backwards compatibility breaks, I don't believe that's an issue here. My proposal and subsequent conversations state that __toArray() is only called if it is explicitly declared and implemented by a developer, otherwise casting an class to an array behaves exactly as it does today. The PHP documentation on magic methods <https://www.php.net/manual/en/language.oop5.magic.php> even specifically mentions: "PHP reserves all function names starting with __ as magical" and cautions "it is recommended that you do not use function names with __ in PHP unless you want some documented magic functionality." So the language itself reserves the double underscore methods for itself and future versions. > as no clear value is added besides more language complexity, and more mixed > cast is encouraged. I don't think supporting another magic method and giving developers control over how an object they create is handled when cast to an array adds complexity. It's on par with the already existing __toString() method. Many libraries use this already to determine how their objects are handled as strings, and to make it easy to convert between types without needing to explicitly implement interfaces: such as Ramsey\Uuid <https://github.com/ramsey/uuid>, and League\Uri <https://github.com/thephpleague/uri-components>. The proposal to add a __toArray() isn't meant to add language complexity, it's meant to add an optional helper for developers to simply converting their objects to arrays, and doing so with magic methods isn't without precedence and is more in line with PHP. -- Steven Wade stevenwad...@gmail.com