php.net |  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
Votes:4
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
 [2018-05-21 10:18 UTC] tobias dot nyholm at gmail dot com
Description:
------------
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 3v4l.org: https://3v4l.org/MMCL3

This bug might be related to https://bugs.php.net/bug.php?id=63816

Test script:
---------------
<?php

declare(strict_types=1);

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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-05-23 12:43 UTC] cmb@php.net
-Package: Unknown/Other Function +Package: Scripting Engine problem
 [2018-05-23 12:43 UTC] cmb@php.net
It occurs to me that this is a duplicate of bug #67270.
 [2020-03-05 17:53 UTC] nikic@php.net
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: Sat Oct 12 10:01:28 2024 UTC