Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117469
Message-ID: <0a1fa315-9716-5c4a-dcd0-8e8532fb86a7@gmx.de>
Date: Thu, 31 Mar 2022 18:03:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: de-DE
To: Ilija Tovilo <tovilo.ilija@gmail.com>,
 PHP internals <internals@lists.php.net>
References: <CAPyj-LBysaB2+jDN9u08T61mEj+ZL3Jd7XEbi==mphjQc2Gn=Q@mail.gmail.com>
In-Reply-To: <CAPyj-LBysaB2+jDN9u08T61mEj+ZL3Jd7XEbi==mphjQc2Gn=Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: Add leading backslash to enum and class names in var_export
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 31.03.2022 at 17:45, Ilija Tovilo wrote:

> We've had two bug reports for var_export not working for enums. The
> reason for that is that var_export does not add a leading backslash to
> names of enums. This will cause them to be resolved as
> `\CurrentNamespace\EnumNamespace\EnumName` instead of just
> `\EnumNamespace\EnumName`.
>
> enum A {
>     case B;
> }
>
> echo var_export(A::B, true), "\n";
>> A::B
>
>
> This is a problem for things like Doctrines ProxyGenerator that embeds
> the result of var_export in classes with namespaces
> (https://github.com/doctrine/common/pull/955). The Doctrine team
> resolved this by adding a `use` of the enum at the top of the file but
> that really shouldn't be necessary.
>
> The same issue already exists for classes.
>
> class C {}
>
> echo var_export(new C(), true), "\n";
>> C::__set_state(array(
>> ))
>
> https://bugs.php.net/bug.php?id=3D64554
>
> Marco Pivetta created a PR that adds leading backslash to all class or
> enum names of var_export. Adding a backslash will make the code work
> both inside or outside namespaces.
> https://github.com/php/php-src/pull/8233
>
> To avoid disruption, I'm proposing to merge this into PHP 8.2 only.
> Unless anybody has any objections to this change I will merge it in a
> few weeks.

It might be worthwhile to point out that this issue already came up
years ago, and after some discussion[1] the idea was rejected back then.

That said, I'm not against changing this now, but would not want to do
that for any of the stable PHP versions.  Targeting PHP 8.2 is fine for me=
.

[1] <https://externals.io/message/67008>

=2D-
Christoph M. Becker