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
