Re: [PHP-DEV] Proposal for a RFC

This is only part of a thread. view whole thread
  105591
May 4, 2019 16:08 kalle@php.net (Kalle Sommer Nielsen)
Hi

Den lør. 4. maj 2019 kl. 17.58 skrev Steven Wade <stevenwadejr@gmail.com>:
> > Hi Internals team! > > I have an idea for a feature that I'd love to see in the language one day and wanted to run the idea by you all. > > The idea is to add a new magic method "__toArray()" that would allow a developer to specifiy how a class is cast to an array. The idea is the same mentality of __toString(), but, for arrays.
While this sounds great and all, I do wonder about the implications it may have on the already existing behavior of type casting an object into an array which returns current public/protected/private property values. While this functionality is not an ideal or by design, it is fairly heavily (ab-)used, meaning that it is a potential BC break without the ability to an alternative. See this example: https://3v4l.org/ONMoi -- regards, Kalle Sommer Nielsen kalle@php.net
  105592
May 4, 2019 16:10 pmjones88@gmail.com (Paul Jones)
> On May 4, 2019, at 11:08, Kalle Sommer Nielsen <kalle@php.net> wrote: > > Hi > > Den lør. 4. maj 2019 kl. 17.58 skrev Steven Wade <stevenwadejr@gmail.com>: >> >> Hi Internals team! >> >> I have an idea for a feature that I'd love to see in the language one day and wanted to run the idea by you all. >> >> The idea is to add a new magic method "__toArray()" that would allow a developer to specifiy how a class is cast to an array. The idea is the same mentality of __toString(), but, for arrays. > > While this sounds great and all, I do wonder about the implications it > may have on the already existing behavior of type casting an object > into an array which returns current public/protected/private property > values.
I find it easy to imagine that objects not implementing __toArray() would continue to exhibit that behavior. -- Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
  105642
May 8, 2019 14:13 stevenwadejr@gmail.com (Steven Wade)
Hi Kalle,

> On May 4, 2019, at 12:08 PM, Kalle Sommer Nielsen <kalle@php.net> wrote: > > Hi > > Den lør. 4. maj 2019 kl. 17.58 skrev Steven Wade <stevenwadejr@gmail.com>: >> >> Hi Internals team! >> >> I have an idea for a feature that I'd love to see in the language one day and wanted to run the idea by you all. >> >> The idea is to add a new magic method "__toArray()" that would allow a developer to specifiy how a class is cast to an array. The idea is the same mentality of __toString(), but, for arrays. > > While this sounds great and all, I do wonder about the implications it > may have on the already existing behavior of type casting an object > into an array which returns current public/protected/private property > values. While this functionality is not an ideal or by design, it is > fairly heavily (ab-)used, meaning that it is a potential BC break > without the ability to an alternative. > > See this example: https://3v4l.org/ONMoi <https://3v4l.org/ONMoi>
That's a great example, thanks for that. I can understand how casting now can be as you say "abused". With my proposal, the default behavior wouldn't change unless someone implemented the __toArray() method on their class, which would simply give them greater control over how that class is represented. In regards to the output of the example you linked, the same is possible today with reflection: https://3v4l.org/Ab51l <https://3v4l.org/Ab51l> If libraries are using casting to gain insight into objects, it seems that they could be updated to use reflection without losing any functionality. -- Regards, Steven Wade stevenwadejr@gmail.com