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

This is only part of a thread. view whole thread
May 13, 2019 18:55 (Marco Pivetta)
On Mon, 13 May 2019, 20:43 Steven Wade, <> 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: >
That example misses the fact that `ReflectionProperty#getValue()` triggers property access guards, which is an extremely important detail for unset and typed properties. See 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 > <> 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 > <>, and League\Uri > <>. >
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