Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117478
MIME-Version: 1.0
References: <CAFPFaM+pJTUQYdiBiL134HK38eQrskE_yCrC_etrk3UXVGhoKg@mail.gmail.com>
In-Reply-To: <CAFPFaM+pJTUQYdiBiL134HK38eQrskE_yCrC_etrk3UXVGhoKg@mail.gmail.com>
Date: Tue, 5 Apr 2022 14:00:53 +0200
Message-ID: <CADyq6s+2H0CXqVVTC3vacwoZmRGiOgo7o0X7Kc+AZtp=mVa+Uw@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ddca3205dbe6fffb"
Subject: Re: [PHP-DEV] Reflection changes due to allow null + false as
 standalone types RFC
From: ocramius@gmail.com (Marco Pivetta)

--000000000000ddca3205dbe6fffb
Content-Type: text/plain; charset="UTF-8"

Probably best with consistency?

 > - Ignore the Reflection changes of the RFC and align the union type with
the current behaviour

This one, specifically.

I'd love to see all nullable types become
`ReflectionUnionType(ReflectionNamedType($t), ReflectionNamedType(null))`,
but that would be a BC break for later on :-)

Marco Pivetta

https://twitter.com/Ocramius

https://ocramius.github.io/


On Tue, 5 Apr 2022 at 13:58, G. P. B. <george.banyard@gmail.com> wrote:

> Hello internals,
>
> During the review of the implementation of the RFC which introduces null
> and false as standalone types there has been a point raised about the
> changes made to reflection. [1]
>
> The current implementation is what follows the RFC, namely to make
> false|null return a ReflectionUnionType instead of a ReflectionNamedType.
> Because of this, I made the rendering of this type union to be false|null
> instead of ?false.
>
> Moreover, the question is if this union type should not be consistent with
> other types and produce a ReflectionNamedType, and have all of the nullable
> types move to ReflectionUnionType at the same time.
>
> I don't mind either way, but as this was voted part of the RFC I feel this
> should be discussed by internals to see if changing the Reflection
> semantics to not align with the RFC is okay.
>
> As there are currently the following options:
> - Keep as the RFC stated with some minor implementation complexity which
> will be resolved when the Reflection changes are made to all other nullable
> types.
> - Ignore the Reflection changes of the RFC and align the union type with
> the current behaviour
> - Break BC and change all nullable types to return a ReflectionUnionType
>
> (I just added the last option for the sake of completeness, but don't think
> breaking BC is the way to go here).
>
> Best regards,
>
> George P. Banyard
>
> [1] https://github.com/php/php-src/pull/7546#discussion_r837900447
>

--000000000000ddca3205dbe6fffb--