Mailinglist
Back

Re: [PHP-DEV] Proposal for a RFC

This is only part of a thread. view whole thread
  105598
view original
May 6, 2019 14:37 stevenwadejr@gmail.com (Steven Wade)
view whole thread
> On May 5, 2019, at 10:59 AM, Ben Ramsey <ben@benramsey.com> wrote:
> 
> 
>> On May 4, 2019, at 09:58, 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
> 
> Using existing language functionality, would it satisfy the similar needs if you implement IteratorAggregate and return an ArrayIterator from the getIterator() method? Obviously, the (array) cast wouldn’t use this, but you could do $object->getIterator()->getArrayCopy().
> 
> I’m not against the proposal. I’m mainly asking if there are other ways in the language today to accomplish similar things. I would prefer to see interfaces used over more magic methods (something like ArraySerializable).



PHP already has the magic built in. The proposal is really just a way to control the magic. We already have "(string) $foo" and "__toString()", so the idea of implementing a "__toArray()" method is bringing a feature more inline with what's already there. 

I think it reads easier and cleaner "(array) $foo", and a simpler as a developer to implement than a mix of chained methods and interfaces.

That being said, adding an interface like `ArraySerializable` might be nice too. I'm seeing technical arguments against adding magic casts, but (just spit-balling here), what if a class implemented a new `ArraySerializable` interace with whatever method it demands, and if that is attempted to be cast to an array either manually by calling "(array) $foo" or PHP attempting to, then the array serialize method is called. ¯\_(ツ)_/¯
  105599
view original
May 6, 2019 14:45 ben@benramsey.com (Ben Ramsey) 
> On May 6, 2019, at 09:37, Steven Wade <stevenwadejr@gmail.com> wrote:
> 
> That being said, adding an interface like `ArraySerializable` might be nice too. I'm seeing technical arguments against adding magic casts, but (just spit-balling here), what if a class implemented a new `ArraySerializable` interace with whatever method it demands, and if that is attempted to be cast to an array either manually by calling "(array) $foo" or PHP attempting to, then the array serialize method is called. ¯\_(ツ)_/¯



That’s how I would prefer to see it work.

BTW, I’m not suggesting `ArraySerializable` as the name. I used that to make a connection to `JsonSerializable`, which I think did a good job of using an interface for this kind of thing (even though it’s not quite the same because there’s no cast for a JSON type).

In some of my open source projects, I’ve had to add `__toString()` to the interfaces to ensure that implementers implement it. It would be nice for my interfaces to instead extend an internal interface like `Stringable`.

-Ben