Re: Re: Proposal for a RFC
| From: | Steven Wade | Date: | Mon, 13 May 2019 18:43:47 +0000 |
| Subject: | Re: Re: Proposal for a RFC | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-105691@lists.php.net to get a copy of this message | ||
> I don't think any of the discussion points mentioned above is resolved
I believe that most of the discussion points mentioned have been addressed and resolved. Regarding
the concern that an array cast is the only operation capable of exposing object state, the same
functionality can be achieved with reflection - as demonstrated here: https://3v4l.org/Dh3PO <https://3v4l.org/Dh3PO>.
> 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 far as backwards compatibility breaks, I don't believe that's an issue here. My
proposal and subsequent conversations state that __toArray() is only called if it is explicitly
declared and implemented by a developer, otherwise casting an class to an array behaves exactly as
it does today. The PHP documentation on magic methods <https://www.php.net/manual/en/language.oop5.magic.php>
even specifically mentions: "PHP reserves all function names starting with __ as magical"
and cautions "it is recommended that you do not use function names with __ in PHP unless you
want some documented magic functionality." So the language itself reserves the double
underscore methods for itself and future versions.
> as no clear value is added besides more language complexity, and more mixed cast is encouraged.
I don't think supporting another magic method and giving developers control over how an object
they create is handled when cast to an array adds complexity. It's on par with the already
existing __toString() method. Many libraries use this already to determine how their objects are
handled as strings, and to make it easy to convert between types without needing to explicitly
implement interfaces: such as Ramsey\Uuid <https://github.com/ramsey/uuid>, and League\Uri <https://github.com/thephpleague/uri-components>.
The proposal to add a __toArray() isn't meant to add language complexity, it's meant to
add an optional helper for developers to simply converting their objects to arrays, and doing so
with magic methods isn't without precedence and is more in line with PHP.
--
Steven Wade
stevenwadejr@gmail.com