Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81843
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.173 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAF+90c8Q4_QQ5V1yWLMUs5NZRz9VH4TC9CPv0PoNp9cjviQ3bw@mail.gmail.com>
References: <CAF+90c9DgfkumH5ADjjykGd4t6Ude1TA70r=C7Vw40xQg3RHrw@mail.gmail.com> <CAGa2bXbg9PumvjhD0q_6+668WXAhqJwZp2qH_+ATkDSk6oHGTw@mail.gmail.com> <73F87BE7-E57C-4275-A435-98C39A751E87@gmail.com> <CAF+90c8Q4_QQ5V1yWLMUs5NZRz9VH4TC9CPv0PoNp9cjviQ3bw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Wed, 04 Feb 2015 22:02:30 +0000
CC: PHP internals <internals@lists.php.net>
Message-ID: <7D2B5777-C636-43B2-8C17-284F407295C5@gmail.com>
Subject: Re: [PHP-DEV] Allow dropping typehints during inheritance
From: rowan.collins@gmail.com (Rowan Collins)

On 4 February 2015 21:25:49 GMT, Nikita Popov <nikita.ppv@gmail.com> wrote:
>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.

I was replying to the idea that a "user may simply write code that handles various types in function body". While a savvy user would only use that to implement contravariance, encouraging it as a possibility risks people implementing covariance or other weirdness because they haven't understood why it's a bad thing to do.

Full support for contravariance wouldn't stop that being possible, but it would give much better examples for people to learn from.

Regards,
-- 
Rowan Collins
[IMSoP]