Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105691
Message-ID: <B07D3213-EC80-4B49-81A4-2A79238FDC1B@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4AEFD8D3-F1D9-42C7-AFBE-E7467A560244"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Mon, 13 May 2019 14:43:47 -0400
In-Reply-To: <CADyq6sJjhShpJQOzdEAXGQedYzOAtsJ83S_wBKQj0tU0HxPjnQ@mail.gmail.com>
Cc: PHP Internals List <internals@lists.php.net>,
 Jessica Mauerhan <jessicamauerhan@gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
References: <FB70FDD7-53AA-4DB4-B747-6E109BE52C2E@gmail.com>
 <1946899E-7EFC-4206-B26D-CD44838315A3@gmail.com>
 <CADyq6sJjhShpJQOzdEAXGQedYzOAtsJ83S_wBKQj0tU0HxPjnQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: Proposal for a RFC
From: stevenwadejr@gmail.com (Steven Wade)

--Apple-Mail=_4AEFD8D3-F1D9-42C7-AFBE-E7467A560244
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> 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>.=20

> 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.=20

> 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




--Apple-Mail=_4AEFD8D3-F1D9-42C7-AFBE-E7467A560244--