On Mon, Nov 21, 2016 at 10:39 AM, Niklas Keller <m...@kelunik.com> wrote:
> Morning Internals, > > I'd like to announce a RFC to allow omitting the type declarations for > parameters in subclasses: > https://wiki.php.net/rfc/parameter-no-type-variance > > PHP doesn't currently allow variance for parameters as checking these for > compatibility isn't possible on compile time. > This limitation is caused by autoloading and doesn't allow widening the > accepted parameters. > > This RFC proposes to allow ommiting the type entirely in a subclass, as > dropping all parameter constraints is > always valid according to the LSP principle. > > We already allow return types being added in subclasses. > > Your feedback is welcome. :-) > > Regards, Niklas > The RFC is a bit lacking in motivation ... The main practical use-case I see for this is post-hoc addition of type-hints on an interface. To cite a particular example we ran into for PHP 7.0: Derick added a DateTimeZone type hint for the third arg of the DateTime::createFromFormat() method [1]. The method is already documented to accept only this class in the manual, but the typehint is not actually present in the implementation. However, this change had to be reverted, because all classes extending DateTime currently don't have this typehint (and adding it would be illegal under LSP), so they started throwing a method signature mismatch warning. Allowing extending classes to drop typehints in accordance with variance-rules allow people to add additional parameter typehints on parent classes without breaking BC. (Adding an additional return typehint would break BC, but it is still a cross-version compatible change, as consumers have the possibility of writing code that is valid under both versions -- something that is currently impossible if you want to add parameter typehints.) Thanks, Nikita [1]: https://github.com/php/php-src/commit/8e19705a93d785cd1ff8ba3a69699b00169fea47
