Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105693
MIME-Version: 1.0
References: <FB70FDD7-53AA-4DB4-B747-6E109BE52C2E@gmail.com>
 <1946899E-7EFC-4206-B26D-CD44838315A3@gmail.com> <CADyq6sJjhShpJQOzdEAXGQedYzOAtsJ83S_wBKQj0tU0HxPjnQ@mail.gmail.com>
 <B07D3213-EC80-4B49-81A4-2A79238FDC1B@gmail.com>
In-Reply-To: <B07D3213-EC80-4B49-81A4-2A79238FDC1B@gmail.com>
Date: Mon, 13 May 2019 20:55:54 +0200
Message-ID: <CADyq6sLtB0V5YqR7DSjxG=sjpr7bCrySuVsEjFWEwBwjtTKWSw@mail.gmail.com>
To: Steven Wade <stevenwadejr@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>, Jessica Mauerhan <jessicamauerhan@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000019620e0588c97828"
Subject: Re: [PHP-DEV] Re: Proposal for a RFC
From: ocramius@gmail.com (Marco Pivetta)

--00000000000019620e0588c97828
Content-Type: text/plain; charset="UTF-8"

On Mon, 13 May 2019, 20:43 Steven Wade, <stevenwadejr@gmail.com> wrote:

> 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.
>

That example misses the fact that `ReflectionProperty#getValue()` triggers
property access guards, which is an extremely important detail for unset
and typed properties.

See https://3v4l.org/BtDs5 for an example of why `(array)` is vital in
reflection/serialisation layers/libraries.


> 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.
>

See example above on the BC break: existing libraries would need to be
adapted to throw eagerly (and reject interactions with) objects
implementing `__toArray`.


> 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 added complexity comes from consumers: a `(string) $something` cast is
problematic if `$something` is of doubtful type, while
`$something->toString()` already restricts the possible types of that
`$something`.

The same accidental complexity comes with unsafe `(array)` casts.


> 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.
>

Helpers need to be helpful: this ain't, as explained above, since a clear
type declaration is a more useful and introspectible way of handling type
conversions, especially with the already excessively complex and bloated
design of objects in the PHP language.

Greets,

Marco

--00000000000019620e0588c97828--