Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114650
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\))
In-Reply-To: <8e168dd0-d937-2791-319e-10aeadb3d647@gmail.com>
Date: Thu, 27 May 2021 13:12:27 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <09012BAA-3428-458A-9221-EDBB89138ECE@newclarity.net>
References: <CAOwTYAtc_xD6n=efmamkAy4ro4KqPKxq18-zXsNriY0280FY2g@mail.gmail.com>
 <319c4288-5934-b218-d6eb-0b787a2cdef1@gmx.net>
 <aac7b654-cbf2-5d02-6ff6-16e5e7ad8793@gmail.com>
 <77CC2E71-65B2-4361-A106-9E36DF4BE509@newclarity.net>
 <8e168dd0-d937-2791-319e-10aeadb3d647@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Consensus Gathering: is_initialized
From: mike@newclarity.net (Mike Schinkel)



> On May 27, 2021, at 12:05 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 27/05/2021 16:33, Mike Schinkel wrote:
>> Since the argument against is_initialized() seems to almost =
universally be that we should not write code that lets type properties =
be uninitialized past the constructor then it would follow that PHP is =
in the wrong to even allow uninitialized state past the constructor?
>=20
>=20
> Yes, that is my view. The problem is that there is currently no easy =
way to enforce this, because constructors are just methods that run =
after the object is created, and there are a handful of ways to create =
objects without calling them at all which would need to be accounted for =
as well.
>=20
>=20
>> If a property is defined as `?int` or `null|int` why should PHP allow =
an uninitialized state to begin with?  Why shouldn't PHP initialize any =
of those properties to null to begin with?
>>=20
>> And for non-nullable, why shouldn't PHP default `int` to 0, `string` =
to `""`, `array` to `[]`, etc.?
>=20
>=20
> Implicitly assigning a default from some magic list would be messy, =
but requiring that the user specified one would be trivial (or would =
have been, when typed properties were added): ?Foo $foo=3Dnull; int =
$bar=3D0; etc
>=20
> The problem is that for non-scalar, non-nullable properties, there is =
no way to specify a default. One solution would have been to simply ban =
such declarations (i.e. require ?Foo $foo=3Dnull rather than Foo $foo) =
but that was considered too restrictive, so marking the properties =
"uninitialized" is the compromise.
>=20
> We're probably stuck with that compromise for now, but continuing to =
treat it primarily as an error state hopefully leaves us room to do =
something cleaner in future if we can work out how.


So we are full circle.=20

Since we cannot guarantee that properties are not in said "error" state =
it begs the question as to why developers shouldn't be able to =
introspect this error state in a performant manner.

-Mike=