Bug #74394 [Com]: 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 Comment by: spam2 at rhsoft dot 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: 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? Previous Comments: ------------------------------------------------------------------------ [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