Am 26.05.2017 um 18:10 schrieb Ryan Pallas:
On Fri, May 26, 2017 at 9:01 AM, li...@rhsoft.net
<mailto:li...@rhsoft.net> <li...@rhsoft.net <mailto:li...@rhsoft.net>>
wrote:
Am 26.05.2017 um 16:26 schrieb Dan Ackroyd:
On 26 May 2017 at 13:23, li...@rhsoft.net
<mailto:li...@rhsoft.net> <li...@rhsoft.net
<mailto:li...@rhsoft.net>> wrote:
does that also fix the issue
https://bugs.php.net/bug.php?id=74394
<https://bugs.php.net/bug.php?id=74394>
Dear Anonymous,
That "issue" is actually 3 issues.
case 1
class A {
public function test($a) {}
}
class B extends A {
public function test(string $a) { }
}
This breaks LSP - because B::test doesn't accept all the things that
A::test can accept and so is unlikely to ever be supported.
and how is that a problem?
A accepts anything
B limits it's inut to a *subset* of "anything"
Because, if I have a function foo(A $a) { $a->test(new Bar()) } that I
cannot pass B into this function, even though it is a subclass of A. You
should be able to pass any subclass where its parent is expected,
allowing parameter narrowing (covariance) would break this.
well, that case is at least a warning
but add a return-type to the parent is a *fatal error* until you update
the child class and that makes introducing return-types harder than it
should be
something like "covariance class {}" would be xtremely helpful for all
that cases where you don't pass objects all day around but have them as
a *library* in a singletone - in such cases there is no technical
difference when you add a retrun-type to the parent class then before
except that what was over years just a "@return integer" is now instead
of a comment a language construct
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
