Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127860
Precedence: bulk
MIME-Version: 1.0
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
In-Reply-To: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
Date: Thu, 3 Jul 2025 16:45:59 +0200
Message-ID: <CAPyj-LCwNznKQVpEQEiCPirMK5Xh+p9CFkhx8C68-3iUT09Bvg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi everyone

On Wed, Jul 2, 2025 at 9:58=E2=80=AFPM Gina P. Banyard <internals@gpb.moe> =
wrote:
>
> It is this time of year again where we proposed a list of deprecations to=
 add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5

Thanks for the bulk RFC. Some thoughts.

> Deprecate __construct() and __destruct() in interfaces

While __construct() is tied to the new expression (at least unless
instantiated through
ReflectionClass::newInstanceWithoutConstructor()), factories creating
instances from class names may still need to check for constructor
compatibility. This is much easier achieved through an interface than
it is through reflection.

With an interface:

interface I {
    public function __construct(string $a, string $b);
}
function some_factory(string $class) {
    if (!is_a($class, I::class)) {
        throw new InvalidArgumentException();
    }
    return new $class('foo', 'bar');
}

Without an interface:

function some_factory(string $class) {
    $reflection =3D new ReflectionClass($class);
    $constructor =3D $reflection->getConstructor();
    if (!$constructor || !$constructor->isPublic()) {
        throw new InvalidArgumentException();
    }
    $params =3D $constructor->getParameters();
    if (count($params) !=3D=3D 2
        || $params[0]->getType()->getName() !=3D=3D 'string'
        || $params[1]->getType()->getName() !=3D=3D 'string') {
        throw new InvalidArgumentException();
    }
    return $class('foo', ['bar']);
}

This implementation is much more complex, and incorrect in multiple ways.

1. We could have more than 2 params, with them being optional.
2. We could use variadics, i.e. function __construct(string ...$s),
which is completely valid.
3. Since parameter types are contravariant, they may be substituted
with union types, mixed, or just completely omitted.

Also note that while LSP for __construct() is not enforced for class
inheritance, it is for interfaces, even across multiple class
hierarchy levels. Maybe there is some issue I'm missing. But if not,
I'm not in favor of deprecating/dropping this feature.

> Deprecate using values of type null and bool as array offsets and when ca=
lling array_key_exists()

The introduction section also lists float as a type to be deprecated
in array offsets:

> Deprecate using values of type null, bool, and float as array offsets and=
 when calling array_key_exists()

Floats used as array offsets that lose precision already emit a
warning. Can you confirm that floats used as array offsets that do not
lose precision will not start emitting a deprecation?

> Deprecate ReflectionClass::getConstant() for missing constants

I don't have strong opinions on this change. However,
ReflectionProperty::getDefaultValue() suffers from a very similar
issue, except that it returns null rather than false
(https://3v4l.org/G2R3l). It would make sense to avoid more
inconsistencies. For example, ReflectionParameter::getDefaultValue()
does throw if the parameter has no default value.

> Deprecate ArrayObject and ArrayIterator with objects

Just to add another issue to the list: It can also change readonly
properties of internal classes that the engine does not expect to ever
change. For example, Enum::$name and Enum::$value. This can break
internal logic assumptions (e.g. hard-coded switch cases to handle
internal enums by name) and cause memory corruption. The same goes for
non-readonly properties guarded with the internal equivalent of
__set().

> Deprecate passing spl_autoload_call() to spl_autoload_unregister()

Is such a check actually useful? We can prevent
spl_autoload_unregister(spl_autoload_call(...)), but we can't prevent
spl_autoload_unregister(fn($c) =3D> spl_autoload_call($c)). It seems
very unlikely for this to happen accidentally, and excluding all
functions that don't make sense to pass is not feasible for obvious
reasons. But I don't care too much.

Ilija