Re: Asymmetric visibility is a BC break

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 <bilge@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