On Tue, Oct 15, 2024, at 19:11, Larry Garfield wrote:
> 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
>
Hey Larry,
First, thank you for this feature. Second, attributes and annotations are a
moot point. Adding attributes didn't render annotations broken and is still
(unfortunately) used today in many codebases running 8.3. So, in other words,
the deprecation of annotations is a framework/codebase/user-level issue and
totally unrelated to attributes and PHP as a language. While attributes helped
with that deprecation, it wasn't caused by them—people could have deprecated
annotations without ever having attributes.
According to Wikipedia (https://en.wikipedia.org/wiki/Backward_compatibility)
> In compilers <https://en.wikipedia.org/wiki/Compiler>, [and interpreters]
> backward compatibility may refer to the ability of a compiler [or
> interpreter] for a newer version of the language to accept source code of
> programs or data that worked under the previous version.
I think this is all we need: just a proper definition. Looking at the issue at
play, we can conclude that it isn't a BC break — code that worked in 8.3 will
continue to work in 8.4. Will things have to be updated (or in my case,
rewritten basically from scratch)? Sure! But there, it becomes a
framework/codebase/user-level issue on whether they will remain backwards
compatible with older versions of PHP.
— Rob
