Re: [PHP-DEV] Re: Proposal for a RFC

This is only part of a thread. view whole thread
  105691
May 13, 2019 18:43 stevenwadejr@gmail.com (Steven Wade)
> 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 stevenwadejr@gmail.com
  105693
May 13, 2019 18:55 ocramius@gmail.com (Marco Pivetta)
On Mon, 13 May 2019, 20:43 Steven Wade, <stevenwadejr@gmail.com> wrote:

> 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. >
That example misses the fact that `ReflectionProperty#getValue()` triggers property access guards, which is an extremely important detail for unset and typed properties. See https://3v4l.org/BtDs5 for an example of why `(array)` is vital in reflection/serialisation layers/libraries.
> 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. >
See example above on the BC break: existing libraries would need to be adapted to throw eagerly (and reject interactions with) objects implementing `__toArray`.
> 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 added complexity comes from consumers: a `(string) $something` cast is problematic if `$something` is of doubtful type, while `$something->toString()` already restricts the possible types of that `$something`. The same accidental complexity comes with unsafe `(array)` casts.
> 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. >
Helpers need to be helpful: this ain't, as explained above, since a clear type declaration is a more useful and introspectible way of handling type conversions, especially with the already excessively complex and bloated design of objects in the PHP language. Greets, Marco