|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76361 Order of extending interfaces should not matter
Submitted: 2018-05-21 10:18 UTC Modified: 2020-03-05 17:53 UTC
Avg. Score:3.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: tobias dot nyholm at gmail dot com Assigned:
Status: Open Package: Scripting Engine problem
PHP Version: 7.2.5 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: tobias dot nyholm at gmail dot com
New email:
PHP Version: OS:


 [2018-05-21 10:18 UTC] tobias dot nyholm at gmail dot com
If an interface that extends two other interfaces, the order of those two other interfaces should not matter. 

I found this bug when I was testing solutions for PSR18 and HTTPlug. Here is an

This bug might be related to

Test script:


interface Response {}

interface Request {}

class RespImpl implements Response {}

class ReqImpl implements Request {}

interface Psr {
    public function sendRequest(Request $request): Response;

interface Httplug {
    public function sendRequest(Request $request);

//interface PsrBridge extends Psr, Httplug {} // does work
interface PsrBridge extends Httplug, Psr {} // does not work

class HttpClient implements PsrBridge {
    public function sendRequest(Request $request): Response {
        return new RespImpl();

$client = new HttpClient();
$response = $client->sendRequest(new ReqImpl());
echo $response instanceof Response ? 'OK' : 'Fail!';

Expected result:
I expect these two lines would give the same result: 

interface PsrBridge extends Psr, Httplug {}
interface PsrBridge extends Httplug, Psr {}

Actual result:
Fatal error: Declaration of Httplug::sendRequest(Request $request) must be compatible with Psr::sendRequest(Request $request): Response in /in/MMCL3 on line 22
Process exited with code 255.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2018-05-23 12:43 UTC]
-Package: Unknown/Other Function +Package: Scripting Engine problem
 [2018-05-23 12:43 UTC]
It occurs to me that this is a duplicate of bug #67270.
 [2020-03-05 17:53 UTC]
This looks fairly tricky for the general case. Say you have interfaces:

interface A {
    public function method(): X|Y;

interface B {
    public function method(): Y|Z;

interface C extends A, B {}

Then it would be possible to satisfy both A and B with a method

    public function method(): Y {}

But I'm not sure how we could really support this.

For the special case described here, it would be enough to check for compatibility in both directions, and pick the one that is compatible. But there may be complications with variance, because we may not be able to determine whether the methods are compatible at the time the to-be-inherited method needs to be determined.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 14 18:01:30 2024 UTC