Re: Proposal for a RFC
| From: | Steven Wade | Date: | Wed, 08 May 2019 14:13:29 +0000 |
| Subject: | Re: Proposal for a RFC | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-105642@lists.php.net to get a copy of this message | ||
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