Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121708
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1108-g3a29173c6d-fm-20231031.005-g3a29173c
MIME-Version: 1.0
Message-ID: <84fcf08c-4f03-4583-9677-c1796bac3325@app.fastmail.com>
In-Reply-To: <A397ECDD-B260-41CF-84C0-6340CB62C561@gmail.com>
References: <2b4591c1-f999-49b5-8061-67db816aa0da@gmail.com>
 <CAEKnhAE9UifgLQJ4yaxC9OrWt1gQiDVo4crSLAUoDyJ_UQadbQ@mail.gmail.com>
 <A397ECDD-B260-41CF-84C0-6340CB62C561@gmail.com>
Date: Fri, 17 Nov 2023 15:58:40 +0000
To: "Rowan Collins" <rowan.collins@gmail.com>
Cc: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC][Discussion] Harmonise "untyped" and "typed" properties
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Nov 17, 2023, at 10:47 AM, Rowan Tommins wrote:
> On 16 November 2023 21:38:48 GMT, Jakub Zelenka <bukka@php.net> wrote:
>>This sounds like a huge BC break. Probably bigger and a bit harder to fix
>>than disallowing dynamic props.
>
> More common, maybe; but trivial to fix: add "=null" at the end of all 
> untyped property declarations that don't already have an initializer. 
> It would be trivial to automate with something like Rector.
>
>
>>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 
> declaration, and it no longer gets initialized to null. The aim of the 
> RFC is to eliminate that distinction, not to encourage typed properties.
>
>
>
> I do however agree that the initial value part is quite disruptive, and 
> am open to suggestions on how to minimise that. A couple that have 
> occurred to me:
>
> - Change the unset() behaviour, which we're already planning to make 
> produce errors in 9.0; but keep the implicit initializer. In other 
> words, make "public $foo;" equivalent to "public mixed $foo=null;" The 
> obvious downside is that it's just as weird a special-case for users to 
> learn as what we have now.

This seems like the easiest way forward, with the fewest breaks.  In particular, I would therefore expect reflection to treat `public $foo` as though it had been `public mixed $foo = null`, and thus normalize how the object looks.  That's one less edge case for me to deal with, so I support that.

As noted, though, there's still readonly to consider.

Of note, both ?? and ??= currently treat uninitialized the same as null; this is a very good feature that is extraordinarily useful, and has the nice side effect of reducing the impact of this change.

--Larry Garfield