Re: Asymmetric visibility is a BC break
| From: | Valentin Udaltsov | 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