Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113956
MIME-Version: 1.0
Date: Mon, 5 Apr 2021 13:14:50 -0400
Message-ID: <CAES=RMtF9FbRgRrigbm8mew38z8Yba9aZobibJCuquOt8a_uWA@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007e745c05bf3cd691"
Subject: Path forward for class_exists with different targeted PHP version implementations
From: jr@rushlow.dev (Jesse Rushlow)

--0000000000007e745c05bf3cd691
Content-Type: text/plain; charset="UTF-8"

Howdy Internals,

I discovered today (purely on accident) that class_exists($subject)
actually parses the "$subect" class in question.

I was attempting to use class_exists(UsesPropertyPromotion::class) to
determine if an attribute implementation existed in order to generate a PHP
8 appropriate class - else fall back to generating a PHP 7 appropriate
class. For context, this check was being written for Symfony's MakerBundle
which generates classes for Symfony projects.

Consequently the conditional worked as expected in PHP 8, but in 7 I
received a Parse Error. See the bug report
https://bugs.php.net/bug.php?id=80938 for additional details. Nikic pointed
out the problem (not a bug) is that w/ autoload === true, class_exists will
load the class.

The purpose of this email is to spark the conversation on a path forward
for code bases that must support multiple versions of PHP and still be able
to use native PHP functions without having to jump through hoops. It would
appear from a userland standpoint that class_exist() is broken / unreliable
if it must first be determined if the class being checked is compatible for
the PHP version used at runtime. Which brings us to the chicken and the
egg...

At the very least this could be a "mental note" for RFC's that introduce
changes that create BC in unexpected ways in userland.

Cheers!
Jesse Rushlow

--0000000000007e745c05bf3cd691--