Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122599
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (1.0)
Date: Sun, 10 Mar 2024 11:18:26 +0700
Message-ID: <FAC6A0A4-FC12-4169-927E-1F99D2B98CD5@koalephant.com>
References: <1773BB80-D9BD-4A0E-B01B-0A9EF402174D@cschneid.com>
In-Reply-To: <1773BB80-D9BD-4A0E-B01B-0A9EF402174D@cschneid.com>
Subject: Re: [PHP-DEV] Idea: Implicit inheriting function argument & return type-hint
To: php internals <internals@lists.php.net>
From: php-lists@koalephant.com (Stephen Reay)



> On 9 Mar 2024, at 21:27, Christian Schneider <cschneid@cschneid.com> wrote=
:
> =EF=BB=BFAm 09.03.2024 um 08:18 schrieb Marc <marc@mabe.berlin>:
>> As the pseudo type `mixed` exists since PHP 8.0, which is already out-of-=
date, I have the feeling it would be better to force people to explicitly wr=
ite `mixed` to widen the type of an overwritten function and let "no type" i=
nherit the argument and return type of the parent.
>>=20
>> Example:
>>=20
>> class A {
>>    public function typed(int $var): int { return $var; }
>>    public function untyped($var) { return $var; } // implicit mixed as no=
 overwrite
>> }
>> class B extends A {
>>    public function typed($var) { return $var; } // implicit int as inheri=
ted from overwritten function
>> }
>=20
> This sounds like a bad idea to me as I cannot look at the function definit=
ion in class B and determine what the type of $var is.
> On top of that: If the type of $var in A is changed then it would automati=
cally also change in B. While this seems convenient it could also break B in=
 subtle ways as the function suddenly gets different types than expected.
>=20
> Regards,
> - Chris

I guess my discussion with Larry was at least part of what you're referring t=
o.

The proposal here would introduce the same problem as we discussed on the ot=
her RFC: inconsistency with what people are used to elsewhere in the languag=
e (eg untyped properties).

It also means that existing code would have the complete opposite effect to p=
reviously, making it a huge BC break. You'd likely have to have two stages: d=
eprecate and then remove use of untyped parameters, and then reintroduce unt=
yped to mean "inherited" type, which still suffers from the issues Christian=
 pointed out.

I could get behind the "first half" of that process:  making a type required=
 (ie deprecating type-less parameters/properties) but I doubt there's enough=
 support for that to pass a vote.=20

Cheers

Stephen=20=