Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125747
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 04 Oct 2024 16:16:13 +0200
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>, PHP
 internals <internals@lists.php.net>, Ayesh Karunaratne <ayesh@php.watch>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add get_declared_enums() function
In-Reply-To: <CAOWwgp=--t8xMEE6Dso9whYKydjHPiXz69PTp=AYOU8en3TjcQ@mail.gmail.com>
References: <66FC7B9F.5070906@adviesenzo.nl>
 <CAOWwgp=--t8xMEE6Dso9whYKydjHPiXz69PTp=AYOU8en3TjcQ@mail.gmail.com>
Message-ID: <80dfd8f02a4921d4772ec3c44cdbedff@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2024-10-04 13:44, schrieb Nicolas Grekas:
> # Introduction of the new function: get_declared_enums()
> 
> About this proposal, I shared a one-liner in the previous thread that 
> shows
> listing only enums is trivial already.
> IMHO we don't need this function since the engine already provides
> everything one needs if they want to list enums. I won't object either, 
> I'm
> just "-0".

Agreed.

> # Deprecation of using class_exists() on enum names
> 
> This is a big NO on my side. This will break perfectly fine code for 
> the
> sake of some high level ideas that matter less is practice than 
> ensuring
> stability of the PHP platform. A BC break has to be worth it and this 
> is
> clearly not the case to me. The canonical examples are checks like
> `class_exists($c) || interface_exists($c, false) || trait_exists($c,
> false)`. This is common code to check if a symbol exists in current 
> PHP.
> Yet, with your RFC, all such checks would become broken immediately.

Also agreed here. I don't think that the RFC lists particularly strong 
arguments in favor of the breaking change. From what I see the main 
argument is perceived consistency. But as can be seen in this 
discussion, it's possible to make the argument of consistency in both 
directions.

I also believe that consistency is a strong argument to make before a 
feature is introduced to not make PHP any more inconsistent, but once 
the "damage is done", making *behavioral* changes would just make the 
damage larger. I'm specifically highlighting *behavioral* here. 
Deprecating something and then later removing it will very visibly break 
the code if one ignores the deprecation notice, but when making a 
behavioral change, code will instead silently misbehave. As Nicolas also 
mentioned this is especially true for the change to 
`get_declared_classes()` which would be unable to emit the deprecation 
notice at all!

Best regards
Tim Düsterhus