Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103202
MIME-Version: 1.0
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com>
 <CALKiJKqgM=YsyqodP-4QNL52q8L05ZZxUD8iyGk9L+O9c9m1+w@mail.gmail.com> <CAF+90c8He-6M_WAKj7B_+fcgJhos+DPQ07afjmGyoNgx7RzE7g@mail.gmail.com>
In-Reply-To: <CAF+90c8He-6M_WAKj7B_+fcgJhos+DPQ07afjmGyoNgx7RzE7g@mail.gmail.com>
Date: Thu, 20 Sep 2018 12:50:45 +0100
Message-ID: <CALKiJKoJXxi+khw-BhPf7DCOV+J279UGBupUHBxEKcaj8re85g@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c80ecf05764c22b5"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000c80ecf05764c22b5
Content-Type: text/plain; charset="UTF-8"

On Thu, 20 Sep 2018 at 11:58, Nikita Popov <nikita.ppv@gmail.com> wrote:

> I do not consider it advisable to require a null initialization as a
> "first iteration" of the proposal. Regardless of what our intention might
> be, the effect of such a restriction will not be "I'm not going to type
> this property for now, because non-nullable types are not supported", it's
> going to be "I'll give this a nullable type even though it isn't, because
> that's better than no type at all." Use of nullable types where they are
> not necessary would be a disastrous outcome of this proposal.
>

This, ultimately, is where we disagree. To me, the "non-nullable types"
this proposal provides are non-nullable in name only, and using them does
little more than adding a comment saying "I promise this won't be null".
Encouraging people to use them gives them a false guarantee, and allowing
them to do so prevents us adding a stricter version of the feature later.



> To move this discussion forward in a productive direction, we need a
> concrete, detailed proposal of how enforcement of initialization should
> work, while being compatible with secondary requirements.
>

It feels to me that many of the "secondary requirements" are actually
separate problems which should be seen as pre-requisites, rather than
constraints. The lazy initialization pattern seems to be a hack around lack
of better support for property accessors. The mention of serializers
needing custom methods of initialisation reminded me of the occasional
discussion of better replacements for Serializable and JsonSerializable.
And so on.

Fixing that list of pre-requisites would obviously take time, which is why
I wanted to buy that time by releasing initialised-only type hints first,
and working towards a greater goal.

However, I've probably beaten this drum long enough. I will hope to be
wrong, and that making things stricter will still be possible later.

Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000c80ecf05764c22b5--