On Mon, Oct 14, 2024, at 10:27 PM, Pierre Joye wrote:
> Hello,
>
> On Mon, Oct 14, 2024, 8:07 AM Bilge <bi...@scriptfusion.com> wrote:
>> On 14/10/2024 01:02, Valentin Udaltsov wrote:
>> > 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`.
>>
>> That seems like a problem they have created for themselves. It seems an
>> error to me to declare software forward-compatible with PHP versions
>> that do not yet exist and thus have clearly not been tested against.
>> Being as it is an error, we shouldn't consider it impinges on PHP's
>> definition of a BC break.
>
>
> As much as I like this new feature and I am more than thankful for the
> work behind it, if a test in codes using a x.y version of php works but
> fails in x.y+1, it is a BC break, no matter how we look at it. A php
> dependency targeting x.* is very common. While it tends to be used less
> frequently as the amount of issues increase, that's not necessarly a
> good thing.
>
> In some cases it is a necessary evil (extension deprecated adding
> warnings, security fix requiring a bc break, f.e.).
>
> However, I am very doubtful here. And I do not know if it can be
> avoided while keeping the new behaviors.
>
> All in all, it would be great to at least agree that there is a BC
> break issue, so it can be addressed according, whatever the final
> decision is.
>
> best,
> Pierre
I think folks are operating with different definitions of "BC Break".
Consider:
// Foreign.php
class Foreign {
public function __construct(public string $name) {}
}
// My code:
$f = new Foreign('beep');
$rProp = (new ReflectionObject($f))->getProperty('name');
if ($rProp->isPublic()) {
$f->name = 'boop';
}
Under PHP 8.0, this code works.
Upgrading to PHP 8.1, this code *still works* exactly the same. Therefore,
there is no BC break.
Upgrading to PHP 8.4, this code *still works* exactly the same. Therefore,
there is no BC break.
Now, someone edits Foreign.php in 8.1 to read:
class Foreign {
public function __construct(public readonly string $name) {}
}
Now, my code will fail, because isPublic() does not guarantee "is writeable"
anymore.
Is this a BC break in PHP?
I can see the argument either way, personally, but I tend toward no. One PHP
version to the next should always be safe to upgrade an *existing* code base.
Just swap out the PHP binary and it should still work the same. We want that.
However, once you start modifying any part of the code (including
dependencies), all bets are off.
Suppose some library switched from using annotations to using attributes. Any
other code that was looking for those annotations is now broken, but it would
be ridiculous to accuse attributes of having broken BC in PHP. Or ancient PHP
4 code that just assumed all properties were public (which they were in PHP 4),
now confronted with PHP 5 code that has private properties. Is that a PHP BC
break? Not at all.
And again, the relevant change here happened in PHP 8.1. This is only
tangentially related to 8.4 at all, because isPublic() has not implicitly meant
is-writeable anymore for three years.
--Larry Garfield
