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.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
