php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #80921 allow parameter type hints for poorly typed interface methods
Submitted: 2021-03-30 20:31 UTC Modified: 2021-03-30 20:51 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: smiley at chillerlan dot net Assigned:
Status: Wont fix Package: Class/Object related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: smiley at chillerlan dot net
New email:
PHP Version: OS:

 

 [2021-03-30 20:31 UTC] smiley at chillerlan dot net 
Description:
------------
Hello! I'd like to be able to add parameter type hints for poorly typed interface methods for type security and consistency.

We're currently allowed to add return types in case they're not declared in the interface or omit existing type hints in the interface, but for some reason the aforementioned probably most important feature is missing.

A userland example would be the dilemma of a PSR-7 update: https://github.com/php-fig/http-message/pull/83

I understand that this might require an RFC, but i don't possess neither the technical insight, nor the mental capacity to start such a process.

Don't mind me if plans/feature request for such an update already exist. :)


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

// a poorly typed interface
interface PoorlyTypedInterface{
	public function methodWithoutTypeHints($string, $int);
}

// currently we're only allowed to add a return type
class PoorlyTypedClass implements PoorlyTypedInterface{
	public function methodWithoutTypeHints($string, $int):array{
		return [$string, $int];
	}
}

// proposal: allow adding parameter type hints
class StronglyTypedClass implements PoorlyTypedInterface{
	public function methodWithoutTypeHints(string $string, int $int):array{
		return [$string, $int];
	}
}



Actual result:
--------------
Fatal error: Declaration of StronglyTypedClass::methodWithoutTypeHints(string $string, int $int): array must be compatible with PoorlyTypedInterface::methodWithoutTypeHints($string, $int)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-03-30 20:51 UTC] requinix@php.net
-Status: Open +Status: Wont fix
 [2021-03-30 20:51 UTC] requinix@php.net 
No parameter type means "mixed", as in any type is accepted. Allowing a child class like StronglyTypedClass to be more restrictive about its *parameter types* violates LSP and the principle of contravariance. *Return types*, on the other hand, can be made more restrictive.

https://en.wikipedia.org/wiki/Liskov_substitution_principle
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
 [2021-03-30 20:52 UTC] tiffany@php.net 
Changing parameter types to allow a more specific type opposes the Liskov Substitution Principle.

Contravariance states parameter types of a child class method can be less specific than its parent class method.

https://www.php.net/manual/en/language.oop5.variance.php
 [2021-03-30 21:07 UTC] smiley at chillerlan dot net 
Thank you for the quick reply! I understand the general problem with LSP, however, the problem i see with PHP is that (scalar) type hints didn't exist before 7.0 and a lot of userland interfaces therefore technically cannot adhere to LSP (even though types may be declared in docblocks). In the example case of PSR-7, implementors are left with countless type checks that could be avoided if it was possible to add type hints.
 [2021-03-30 21:24 UTC] yvdg dot sgegeg at sgeg dot hh 
"No parameter type means mixed" makes it that idiotic because a specific type in an extended class is compatible

this behavior makes it impossible to prepare the implementation of type hints in base classes by first add them to extended classes

and no in the real world you can't always deploy everything atomic 

frankly without that limitation you could state in the documentation that every extended class has to implement native type hints based on the existing phpdoc because release xyz or the baseclass will have them too
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue May 13 10:01:27 2025 UTC