Bug #74394 [Dup]: incosistent: Declaration of B::test(string $a) should be compatible

Edit report at https://bugs.php.net/bug.php?id=74394&edit=1 ID: 74394 Updated by: nikic@php.net Reported by: spam2 at rhsoft dot net Summary: incosistent: Declaration of B::test(string $a) should be compatible Status: Duplicate Type: Bug Package: *General Issues Operating System: Linux PHP Version: 7.1.4RC1 Block user comment: N Private report: N New Comment: Of course it is possible to extend existing libraries with return types -- you just have to realize that, just like most changes to method signatures, this is a breaking change and must be versioned accordingly. Whether it results in a warning or a fatal error is irrelevant, it is a semver major change in any case. It appears to me that your actual problem is a very broken management of project dependencies and/or deployments -- I can hardly believe that I'm seeing a bug report in 2017 that is essentially based on "I do breaking code updates in production and then fix things based on warning logs". Previous Comments: ------------------------------------------------------------------------ [2017-04-08 23:41:33] spam2 at rhsoft dot net so you are aware that it WILL NEVER be possible to extend existing libraries which are not defined as "final class" with return-types in PHP? > And a quick reminder: strict_types affects function *calls*, not declarations i know that - but i won't ever write any new script which does not start with <?php declare(strict_types=1); ------------------------------------------------------------------------ [2017-04-08 23:17:19] requinix@php.net No type implies it returns mixed so returning a string instead is allowed by LSP, and supporting overriding mixed was a necessary exception to the "return types are invariant" rule (which IIRC was mostly a technical limitation). And while some language changes in the past only introduced warnings for newly-invalid designs (like with case 1), using return types incorrectly is intentionally fatal and is a style I would expect to continue. If you want to know more, or at least more than I can remember given it's been three years, then you should check the RFC and read through the internals mailing list's archives to find its associated discussions. https://wiki.php.net/rfc http://news.php.net/php.internals (c. Mar 2014) or a third-party aggregator And a quick reminder: strict_types affects function *calls*, not declarations. ------------------------------------------------------------------------ [2017-04-08 22:15:31] spam2 at rhsoft dot net and by which logic can you add the return type to B::test() without any warning while in case of type-hints you get always warnings if there is the sligtest difference? and by which logic this needs to be FATAL ERROR instead just a warning? ------------------------------------------------------------------------ [2017-04-08 21:32:03] requinix@php.net Haven't you complained about this before? Your example allows B::test() to return anything. That conflicts with A::test's requirement that it returns a string. Similar problem with case 1 in fact. Having to deal with child classes when you want to alter a parent is a problem inherent to OOP as a whole. And before you mention polymorphism, return types are invariant for the time being. ------------------------------------------------------------------------ [2017-04-08 21:18:11] spam2 at rhsoft dot net Description: ------------ Warning: Declaration of B::test(string $a) should be compatible with A::test($a) Fatal error: Declaration of B::test($a) must be compatible with A::test($a): string in /mnt/data/downloads/test.php on line 17 ___________________________________________ case 1: Warning - that can be handeled <?php declare(strict_types=1); class A { public function test($a) { } } class B extends A { public function test(string $a) { } } ?> ___________________________________________ case 2: introduce a return type in the extended class is even possible <?php declare(strict_types=1); $x = new B(); class A { public function test($a) { } } class B extends A { public function test($a): string { } } ?> ___________________________________________ case 3: add return types in the base class breaks any code which extends it and that makes it just impossible to introduce return-types on a larger code base becaus eyou would need to *first* add the return types to every extended class and only after that is done you can add it to the shared library providing the base class - in case of scalar type-hints you just need to "tail -f" on the error logs and fix the warnings while all sites are online and working <?php declare(strict_types=1); $x = new B(); class A { public function test($a): string { } } class B extends A { public function test($a) { } } ?> Expected result: ---------------- only a warning when the base class defines a return type and the extend class not to have a way fix the dfinitions in all code wich extends the base class while the pages ar enot broken Actual result: -------------- impossible to introduce return types on classes which are extended without touch *before* any extending code - that is not realistic in case of hundrets of virtual hosts and more important makes it impossible for anybody who publishes php-classes to add return-types without completly break users code ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74394&edit=1