Hi Steven, As it currently stands, the array cast is the only operation capable of exposing object state without triggering any kind of access guards: it is very much required for anything that works with reflection and typed properties, and possibly the only operation in PHP that operates on state without some contraption intercepting its execution.
It is also necessary to distinguish dynamic properties from declared object state. For comparison, all of the following have side-effects due to the complexity of the language: * isset() * unset() * property read * property write * ReflectionProperty#getValue() * ReflectionProperty#setValue() Overall, this is problematic, and introduces more magic that I'd gladly avoid, in an endpoint used to work around all the engine magic (the only stable one so far). >From my end, this sounds like a bad idea, because it removes one of the very very few referentially transparent guarantees (if not the only one, when dealing with objects) from the language. Greets, Marco On Sat, 4 May 2019, 16:58 Steven Wade, <stevenwad...@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
