Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81842
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <73F87BE7-E57C-4275-A435-98C39A751E87@gmail.com>
References: <CAF+90c9DgfkumH5ADjjykGd4t6Ude1TA70r=C7Vw40xQg3RHrw@mail.gmail.com>
	<CAGa2bXbg9PumvjhD0q_6+668WXAhqJwZp2qH_+ATkDSk6oHGTw@mail.gmail.com>
	<73F87BE7-E57C-4275-A435-98C39A751E87@gmail.com>
Date: Wed, 4 Feb 2015 22:25:49 +0100
Message-ID: <CAF+90c8Q4_QQ5V1yWLMUs5NZRz9VH4TC9CPv0PoNp9cjviQ3bw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdcab84d86033050e49d41b
Subject: Re: [PHP-DEV] Allow dropping typehints during inheritance
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7bdcab84d86033050e49d41b
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 4, 2015 at 10:17 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 4 February 2015 21:02:30 GMT, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> >Hi Nikita,
> >
> >On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov <nikita.ppv@gmail.com>
> >wrote:
> >
> >> Currently we do not allow [1] removing a typehint during inheritance.
> >For
> >> example the following code is not valid:
> >>
> >>     interface A {
> >>         public function method(Typehint $param);
> >>     }
> >>     class B implements A {
> >>         public function method($param);
> >>     }
> >>     // Fatal error: Declaration of B::method() must be compatible
> >with
> >> A::method(Typehint $param)
> >>
> >> The above code does *not* constitute an LSP violation, because
> >B::method()
> >> accepts more inputs than A::method(). However we still forbid it.
> >>
> >> This is an issue, because it makes it impossible to add typehints to
> >> parameters at a later point in time. I've seen this issue come up
> >both in
> >> userland code, as well as in a recent DateTime change, see
> >>
> >>
> >
> https://github.com/php/php-src/commit/8e19705a93d785cd1ff8ba3a69699b00169fea47
> >> .
> >>
> >> Instead of reverting the DateTime BC break, I'm wondering if it
> >wouldn't be
> >> better to fix the root cause by making the inheritance check less
> >strict
> >> and allow removing typehints?
> >>
> >
> >I can understand your reason. It's reasonable perfectly.
> >Template is better, but PHP is weakly typed language.
> >I think it's acceptable.
> >
> >Since Dmitry agreed to introduce DbC, if he like the syntax, etc and
> >proposal is passed.
> >DbC may be used to check various types or user may simply write code
> >that
> >handles
> >various types in function body.
>
> This is actually my fear: that people will misunderstand this as an excuse
> to write invalid type checks, such as ones which are tighter rather than
> looser than the parent class (it takes a bit of careful thought to
> understand why this is wrong). Unfortunately, we don't have a keyword for
> explicitly allowing any value, or even a base for all objects, so I guess
> we have to take that risk, but at least if contravariance were fully
> supported, we could have clear examples of correct usage.
>
> (Incidentally, I'm not sure how templates are relevant - this is purely
> about inheritance and LSP of ordinary objects.)
>
>
Maybe I wasn't clear here. I do not propose to allow any code that violates
LSP. You will not be able to add a parameter typehint if the parent doesn't
have one and you will not be able to change a typehint to a different
class. I'm only proposing to support parameter contravariance to the
limited degree we are capable of implementing currently.

Nikita

--047d7bdcab84d86033050e49d41b--