Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81841
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAGa2bXbg9PumvjhD0q_6+668WXAhqJwZp2qH_+ATkDSk6oHGTw@mail.gmail.com>
References: <CAF+90c9DgfkumH5ADjjykGd4t6Ude1TA70r=C7Vw40xQg3RHrw@mail.gmail.com> <CAGa2bXbg9PumvjhD0q_6+668WXAhqJwZp2qH_+ATkDSk6oHGTw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Wed, 04 Feb 2015 21:17:14 +0000
To: PHP internals <internals@lists.php.net>
Message-ID: <73F87BE7-E57C-4275-A435-98C39A751E87@gmail.com>
Subject: Re: [PHP-DEV] Allow dropping typehints during inheritance
From: rowan.collins@gmail.com (Rowan Collins)

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.)

-- 
Rowan Collins
[IMSoP]