Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121704
Date: Fri, 17 Nov 2023 10:47:25 +0000
CC: PHP Internals <internals@lists.php.net>
User-Agent: K-9 Mail for Android
In-Reply-To: <CAEKnhAE9UifgLQJ4yaxC9OrWt1gQiDVo4crSLAUoDyJ_UQadbQ@mail.gmail.com>
References: <2b4591c1-f999-49b5-8061-67db816aa0da@gmail.com> <CAEKnhAE9UifgLQJ4yaxC9OrWt1gQiDVo4crSLAUoDyJ_UQadbQ@mail.gmail.com>
Message-ID: <A397ECDD-B260-41CF-84C0-6340CB62C561@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_=5BRFC=5D=5BDiscussion=5D_Harmo?= =?US-ASCII?Q?nise_=22untyped=22_and_=22typed=22_properties?=
From: rowan.collins@gmail.com (Rowan Tommins)

On 16 November 2023 21:38:48 GMT, Jakub Zelenka <bukka@php=2Enet> wrote:
>This sounds like a huge BC break=2E Probably bigger and a bit harder to f=
ix
>than disallowing dynamic props=2E

More common, maybe; but trivial to fix: add "=3Dnull" at the end of all un=
typed property declarations that don't already have an initializer=2E It wo=
uld be trivial to automate with something like Rector=2E


>Maybe it would be better to do this as some sort of opt in behaviour

We already have the opt-in behaviour: add "mixed" to a property declaratio=
n, and it no longer gets initialized to null=2E The aim of the RFC is to el=
iminate that distinction, not to encourage typed properties=2E



I do however agree that the initial value part is quite disruptive, and am=
 open to suggestions on how to minimise that=2E A couple that have occurred=
 to me:

- Change the unset() behaviour, which we're already planning to make produ=
ce errors in 9=2E0; but keep the implicit initializer=2E In other words, ma=
ke "public $foo;" equivalent to "public mixed $foo=3Dnull;" The obvious dow=
nside is that it's just as weird a special-case for users to learn as what =
we have now=2E
- Have a longer timeline: fix the unset() behaviour in 9=2E0, and the init=
ializer in 10=2E0=2E But that just postpones both the pain and the gain=2E
- Actually require all properties to have a type at some point in the futu=
re, so the behaviour of untyped properties becomes a moot point=2E I'm pret=
ty sure this is a non-starter since we didn't even manage to remove "var" i=
n favour of "public", but I wanted to say it for completeness=2E

Maybe someone can come up with some other variation or compromise?

Regards,

--=20
Rowan Tommins
[IMSoP]