Allow dropping typehints during inheritance

-----Ursprüngliche Nachricht-----
Von: Robert Stoll [mailto:php@tutteli.ch]
Gesendet: Mittwoch, 4. Februar 2015 20:24
An: 'Nikita Popov'; 'PHP internals'
Betreff: AW: [PHP-DEV] Allow dropping typehints during inheritance

-----Ursprüngliche Nachricht-----
Von: Nikita Popov [mailto:nikita.ppv@gmail.com]
Gesendet: Mittwoch, 4. Februar 2015 19:50
An: PHP internals
Betreff: [PHP-DEV] Allow dropping typehints during inheritance

Hi internals!

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/8e19705a93d785cd1ff8ba3a69699b00
169fea47
.

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?

Thanks,
Nikita

[1] This is a fatal error when interfaces or abstract methods are involved, otherwise this is an E_STRICT error.

I do not entirely agree here since what you are proposing is not to introduce contravariance for parameters (which I would
support) but remove the check entirely.
In this sense it is an LSP violation (you cannot substitute A with B and guarantee the correctness) and therefore should not
be introduced into PHP.

Cheers,
Robert

--

I have to correct myself, without type hint is equal to say any type and in this sense it is contravariance, all good to go :)

On Wed, Feb 4, 2015 at 9:04 PM, Rowan Collins rowan.collins@gmail.com
wrote:

Nikita Popov wrote on 04/02/2015 18:49:

Hi internals!

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.

For those that missed it, or have forgotten, there was a discussion of
covariance and contravariance in November, kicked off by Levi's concerns
over return type hints: http://grokbase.com/t/php/php-
internals/14bstfz0pg/rfc-discussion-return-type-variance-checking

In particular, this Wikipedia article explains the concepts very well
(although once you get into generics it all gets a bit complicated, and
irrelevant to us right now): http://en.wikipedia.org/wiki/
Covariance_and_contravariance_(computer_science) <
http://en.wikipedia.org/wiki/Covariance_and_contravariance_
%28computer_science%29#Covariant_method_return_type>

Removing the typehint is a special case of contravariance, because it
means "accept any type", and parameter contravariance in a nutshell is "a
child implementation must accept at least what the parent accepts, but may
also accept more".

The current situation (invariance) is quite intuitive - the signatures
must match - and full contravariance can be explained fairly easily -
"B:method must accept all values accepted by A::method". My worry is that
people won't understand why this particular special case is allowed, and
may think PHP is just letting them be sloppy and remove other people's type
hints.

The other thing to consider is whether the same special case should be
added (in reverse) to return type hints - a sub-class could introduce a
return type hint, as long as the parent class did not already declare one.

Whatever we choose, we must find a solution that is unique and spread into
all the core language and core exts.
And we have to think about BC : if we choose something more strict, we will
generate more BC breaks for the switch to PHP7, which is not really a good
thing.

However, I'm all good for us to find a clear solution on type parameters,
return types, extended type hints ... whatever other RFC will be accepted
about this kind of subject.
PHP7 should also be the moment we turn PHP into a more consistent, mature
and professional language.

And on the way to make the right choice, why not start by having a look at
what other languages provide ?

Julien Pauli

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]

Hi Hannes,

So what it supports "more inputs"?
It does constitute an LSP violation. "more inputs" is not what the
guarantee is at all, if that is what you want you'd typehint on a
interface.

It is a LSP failure to allow a string, or any other scalar value, when
the parent requires a specific type/object.

It sucks that we fail our arginfo very frequently, but this is the way it is :]

An interface requires only a minimum standard for accepted input. If a class implementing that interface allows a wider range of values, but still allows at least what the interface requires it to, it is not an LSP violation. Scalars are not special.

Andrea Faulds
http://ajf.me/

Hannes Magnusson wrote on 04/02/2015 23:58:

Hi internals!

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.
So what it supports "more inputs"?
It does constitute an LSP violation. "more inputs" is not what the
guarantee is at all, if that is what you want you'd typehint on a
interface.

Have a look at the Wikipedia article on covariance and contravariance;
the idea is that if you know you have a container which can contain
Cats, a custom implementation that also happens to accept Dogs is fine,
but an implementation that only accepts Kittens is not, because the
object is contractually required to accept any Cat that you give it.

Return types are the reverse, because the object is contractually
required to return you nothing but Cats, so returning a Dog would be a
violation; but constraining itself to only return Kittens doesn't affect
the contract you have with it.

The special case proposed here is that the lack of type hint means "any
type", as though you were type hinting the base of all possible types.
Thus removing a typehint on a parameter does not allow the object to
violate the parent's contract, and nor does adding a return typehint.

However, the fact that this is tricky to understand is probably a big
problem for it. The Wikipedia article notes that few languages implement
parameter contravariance, mostly because they'd have to mix it with
type-based function overloading, making real-life examples hard to find.

Regards,

Rowan Collins
[IMSoP]

If you consider the lack of an explicit type to mean the theoretical
"Any" type which is a supertype of all types then dropping the hint is
a form of contravariance. I would prefer to support normal
contravariance for parameter types in which this is just a special
case. However, I am not sure I would be against it without regular
contravariance support if it came to a vote.