Re: [RFC] [Discussion] Add get_declared_enums() function

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