Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125744
Precedence: bulk
MIME-Version: 1.0
References: <66FC7B9F.5070906@adviesenzo.nl>
In-Reply-To: <66FC7B9F.5070906@adviesenzo.nl>
Date: Fri, 4 Oct 2024 13:44:51 +0200
Message-ID: <CAOWwgp=--t8xMEE6Dso9whYKydjHPiXz69PTp=AYOU8en3TjcQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add get_declared_enums() function
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
Cc: PHP internals <internals@lists.php.net>, Ayesh Karunaratne <ayesh@php.watch>
Content-Type: multipart/alternative; boundary="000000000000a45d330623a533f4"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000a45d330623a533f4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Juliette,

L.S.,
>
> After the earlier discussion [1] regarding this topic in August, it is ou=
r
> pleasure to present the RFC to add a `get_declared_enums()` function to P=
HP
> for discussion.
>
> https://wiki.php.net/rfc/get_declared_enums
>
> We look forward to your feedback and hope for a constructive discussion.
>
>
# 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".

# 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.

BTW, this makes me wonder if we could have a new symbol_exists() function,
that'd basically do the above checks in one go? Mixing this idea with
Claude's, the signature could be symbol_exists($class, $filter =3D -1,
$autoload =3D true), where $filter is a bitfield that'd allow listing only
classes, abstract classes, interfaces, enums, traits at will?

# Change of the return value of get_declared_classes()

This proposal is problematic on two aspects:

   1. The planned BC break feels needless to me. Its motivation is very
   moot compared to its impact on the PHP community, which will be forced t=
o
   update perfectly fine code.
   2. The BC break is planned without any ahead-of-change deprecation
   notice (except doc of course). From a deprecation policy POV, we reject
   this practice in the Symfony community. We don't do "hard BC breaks", or
   "unannounced" ones: we mandate that any BC break is first announced in t=
he
   current major. This ensures the community won't miss the notice, and won=
't
   discover the BC break when it's very late and thus costly. There is alwa=
ys
   a way to follow that policy, so I'd strongly recommend adopting this
   practice in PHP itself, and in this RFC today. Here, this could be done =
by
   either keeping the function as is in PHP 9, or just deprecating it (in
   favor of get_declared_symbols()?)


You've been a rightfully vocal criticizer of BC breaks / deprecations in
PHP. Please help the vast part of the community that favors stability =F0=
=9F=99=8F

Nicolas

--000000000000a45d330623a533f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Juliette,<br></div><br><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 =20

   =20
 =20
  <div bgcolor=3D"#FFFFFF">
    <font size=3D"-1"><font face=3D"Verdana">L.S.,<br>
        <br>
        After the earlier discussion [1] regarding this topic in August,
        it is our pleasure to present the RFC to add a
        `get_declared_enums()` function to PHP for discussion.<br>
        <br>
        <a href=3D"https://wiki.php.net/rfc/get_declared_enums" target=3D"_=
blank">https://wiki.php.net/rfc/get_declared_enums</a><br>
        <br>
        We look forward to your feedback and hope for a constructive
        discussion.<br>
        <br></font></font></div></blockquote><div><br></div><div># Introduc=
tion of the new function: get_declared_enums()</div><div><br></div><div>Abo=
ut this proposal, I shared a one-liner in the previous thread that shows li=
sting only enums is trivial already.</div><div>IMHO we don&#39;t need this =
function since the engine already provides everything one needs if they wan=
t to list enums. I won&#39;t object either, I&#39;m just &quot;-0&quot;.<br=
></div><div><br></div><div># Deprecation of using class_exists() on enum na=
mes</div><div><br></div><div>This is a big NO on my side. This will break p=
erfectly fine code for the sake of some high level ideas that matter less i=
s practice than ensuring stability of the PHP platform. A BC break has to b=
e worth it and this is clearly not the case to me. The canonical examples a=
re checks like `class_exists($c) || interface_exists($c, false) || trait_ex=
ists($c, false)`. This is common code to check if a symbol exists in curren=
t PHP. Yet, with your RFC, all such checks would become broken immediately.=
</div><div><br></div><div>BTW, this makes me wonder if we could have a new =
symbol_exists() function, that&#39;d basically do the above checks in one g=
o? Mixing this idea with Claude&#39;s, the signature could be symbol_exists=
($class, $filter =3D -1, $autoload =3D true), where $filter is a bitfield t=
hat&#39;d allow listing  only classes, abstract classes, interfaces, enums,=
 traits at will?</div><div><br></div><div># Change of the return value of g=
et_declared_classes()</div><div><br></div><div>This proposal is problematic=
 on two aspects:</div><div><ol><li>The planned BC break feels needless to m=
e. Its motivation is very moot compared to its impact on the PHP community,=
 which will be forced to update perfectly fine code.</li><li>The BC break i=
s planned without any ahead-of-change deprecation notice (except doc of cou=
rse). From a deprecation policy POV, we reject  this practice in the Symfon=
y community. We don&#39;t do  &quot;hard BC breaks&quot;, or &quot;unannoun=
ced&quot; ones: we mandate that any BC break is first announced in the curr=
ent major. This ensures the community won&#39;t miss the notice, and won=
9;t discover the BC break when it&#39;s very late and thus costly. There is=
 always a way to follow that policy, so I&#39;d strongly recommend adopting=
 this practice in PHP itself, and in this RFC today. Here, this could be do=
ne by either keeping the function as is in PHP 9, or just deprecating it (i=
n favor of get_declared_symbols()?)</li></ol><div><br></div><div>You&#39;ve=
 been a rightfully vocal criticizer of BC breaks / deprecations in PHP. Ple=
ase help the vast part of the community that favors stability =F0=9F=99=8F<=
/div><div><br></div><div>Nicolas<br></div></div></div></div>

--000000000000a45d330623a533f4--