Re: Re: Proposal for a RFC
| From: | Marco Pivetta | Date: | Mon, 13 May 2019 17:51:40 +0000 |
| Subject: | Re: Re: Proposal for a RFC | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-105690@lists.php.net to get a copy of this message | ||
Hi Steven,
On Mon, 13 May 2019, 15:46 Steven Wade, <stevenwadejr@gmail.com> wrote:
> > On May 4, 2019, at 10:58 AM, Steven Wade <stevenwadejr@gmail.com> wrote:
> >
> > 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.
> >
> > I would personally love this feature and those I've run it by were also
> excited by the idea. So I'm soliciting feedback in hopes that things go
> well and I can officially write the RFC. As for implementation, Sara
> Golemon is awesome and while chatting a few months back, knocked out a
> proof-of-concept implementation <
>
> https://github.com/sgolemon/php-src/tree/experimental.toarray>.
> There's
> still work to be done if this proposal gets to the RFC phase, but again,
> just gauging interest here.
> >
> > I appreciate any feedback you all can provide.
> >
> > Thanks,
> >
> > - Steven Wade
>
> Hi all, I wanted to re-ping the list to see if there is any more feedback
> on this proposal? Any technical concerns or true BC changes?
>
> This feature wouldn't be as exciting as the others in 7.4, but I think
> it'd be a nice little helper, and the community feedback I've received from
> developers has been positive, so I'd like to keep the conversation going.
>
I don't think any of the discussion points mentioned above is resolved: 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 no clear value is added besides more language complexity,
and more mixed cast is encouraged.
Greets,
Marco
>