On Wed, Feb 4, 2015 at 10:17 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:
> On 4 February 2015 21:02:30 GMT, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> >Hi Nikita,
> >
> >On Thu, Feb 5, 2015 at 3:49 AM, Nikita Popov <nikita....@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
