Re: Asymmetric visibility is a BC break

From: Date: Mon, 14 Oct 2024 02:37:50 +0000
Subject: Re: Asymmetric visibility is a BC break
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to internals+get-125794@lists.php.net to get a copy of this message
On Mon, 14/10/2024 05:01, Jordan LeDoux <jordan.ledoux@gmail.com>: > > > > On Sun, Oct 13, 2024 at 5:03 PM Valentin Udaltsov <udaltsov.valentin@gmail.com> wrote: >> >> On Mon, 14 Oct 2024 at 01:28, Jordan LeDoux <jordan.ledoux@gmail..com>: >> > Backwards compatible has never, in any work I've done through my entire career, >> > meant something like "if you take old code and then update it to the new version incorrectly, >> > it doesn't work"... that seems... obvious? >> > >> > What exactly is the claim being made here? Because it sounds like the claim is very >> > much that second "definition". >> > >> > Jordan >> >> Hi, Jordan! >> >> The problem is that in practice most of the PHP libraries consider >> themselves to be compatible with newer PHP versions. >> >> For instance, Symfony PropertyInfo uses "php": >> ">=8.2" constraint in >> its composer.json. However, it is not compatible with PHP >> 8.4, I've >> just created an issue: >> https://github.com/symfony/symfony/issues/58556 >> >> The end user will be the victim, because `composer require >> symfony/property-info` will happily install property-info v7.1.4 for >> PHP 8.4, but it's not gonna work. >> >> -- >> Valentin > > > How does a library that uses code that will not even compile (like > readonly or private(set)), but > claims to not require a PHP version that uses the syntax, suddenly make a BC problem for the > language? Composer allows libraries to set minimum PHP versions for releases. Any time you update > your libraries, you may have to update your code which uses it. That's just part of how > libraries work. > > Jordan First of all, I have already agreed above that PHP does not have a BC break here. Now we are discussing the potential problems in the PHP ecosystem and how they could be mitigated. > Composer allows libraries to set minimum PHP versions for releases. I think you've got the problem wrong. The problem is about the maximum version, not the minimum one. Consider the Symfony issue I've just reported: https://github.com/symfony/symfony/issues/58556 Symfony PropertyInfo requires php >= 8.2. And it is written in PHP 8.2 syntax. So it can be safely installed and used in PHP 8.2 and 8.3. In other words it's forward compatible. However, the php >= 8.2 constraint also allows installing it in PHP 8.4. And as it turned out, PropertyInfo is not ready for 8.4 syntax (see my reproducer https://github.com/vudaltsov/symfony-property-access-php84). In my opinion, this is a problem, because a PHP 8.4 user can install the library without any obstacles and only later find out that `private (set)` properties do not work as expected there. Ideally symfony/property-info should not be installable until it ensures to be compatible with all the PHP 8.4 features. So, its PHP constraint should be >=8.2 && <8.4. And then >=8.2 && <8.5, once the tests pass for PHP 8.4 features. -- Best regards, Valentin

« previous php.internals (#125794) next »