Re: Re: Proposal for a RFC

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