> On May 4, 2019, at 12:08 PM, Kalle Sommer Nielsen <firstname.lastname@example.org> wrote:
> Den lÃ¸r. 4. maj 2019 kl. 17.58 skrev Steven Wade <email@example.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.