Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81846
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c9DgfkumH5ADjjykGd4t6Ude1TA70r=C7Vw40xQg3RHrw@mail.gmail.com>
References: <CAF+90c9DgfkumH5ADjjykGd4t6Ude1TA70r=C7Vw40xQg3RHrw@mail.gmail.com>
Date: Wed, 4 Feb 2015 15:58:06 -0800
Message-ID: <CADNQb0Wy8nsMJ3yO1D=bXq3YW-k8-6s7_97xzAv1rNAdG0cuAg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Allow dropping typehints during inheritance
From: hannes.magnusson@gmail.com (Hannes Magnusson)

On Wed, Feb 4, 2015 at 10:49 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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.


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 :]

-Hannes