Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123374
Precedence: bulk
MIME-Version: 1.0
References: <CAAX=eQNH0xyoRkMDThvG_aNS5Hub3tFD52v4PY3OZKT_zWaMmg@mail.gmail.com>
 <CAPzBOBN1M3H-ueqUtzfb_HPv2jZeDaYVTvXideVnx9QYG6LKeA@mail.gmail.com>
 <CAAX=eQPiRs0sq5z2xdtfV9bnf0waV6O+QaAUEfcM90Pwf3+M=g@mail.gmail.com> <878c09ca-860e-4c0c-85ae-2cd0246cda3c@rwec.co.uk>
In-Reply-To: <878c09ca-860e-4c0c-85ae-2cd0246cda3c@rwec.co.uk>
Date: Tue, 21 May 2024 00:05:45 +0200
Message-ID: <CAAX=eQN1s+YgA4w605Ec-yQ7KARortQf19RwqtLTs9B=ZG3W+g@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] Checking uninitialized class properties
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000df23e50618e9e7bf"
From: cardamoneluigi@gmail.com (Luigi Cardamone)

--000000000000df23e50618e9e7bf
Content-Type: text/plain; charset="UTF-8"

On 18/05/2024 18:08, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:

>
> In my opinion - and I stress that others may not share this opinion -
> the entire concept of "uninitialized properties" is a wart on the
> language, which we should be doing our best to eliminate, not adding
> more features around it.
>
> As a bit of background, the concept was created when typed properties
> were being added, to handle a limitation of the language: given the
> declaration "public Foo $prop;" there is no way to specify an initial
> value which meets the type constraint. For nullable properties, you can
> write "public ?Foo $prop=null;" but since PHP (thankfully) distinguishes
> nullable and non-nullable types, you can't write "public Foo $prop=null;"
>
> Some languages, e.g. Swift, require that all properties are initialised
> before the constructor returns, but retrofitting this to PHP was
> considered impractical, so instead it was left to a run-time error: if
> you fail to initialise a property, you will get an error trying to
> access it.
>
> To track that, the engine has to record a special state, but assigning a
> meaning to that error state is a bit like using exceptions for flow
> control. It would be more in keeping with the original purpose to have
> an object_is_valid() function, which returned false if *any* property
> had not been initialised to a valid value.
>
>
> PHP actually has a bewildering variety of such special states. In a
> different compromise added at the same time, calling unset() on a typed
> property puts it into a *separate* state where magic __get and __set are
> called, which they are not if the property has simply not yet been
> assigned, e.g. https://3v4l.org/C7rIF
>
> I have always found this a mess. If a property says it is of type
> "?int", I want to know that it will always be an integer or null, not
> "int or null or uninitialised or unset". If it needs more than one
> non-integer state, that should be specified in the type system, e.g.
> "int|NotApplicable|NotSpecified|NotLoaded".
>
>
I get your point. Now I see "uninitialised" as a dangerous thing.
Unfortunately this state exists and I don't see any general way to
avoid objects with these properties. Fighting the "uninitialised" is
something big that we may try to discuss in another thread.
We have to deal with this state and a syntax to reliably check
those invalid properties will be helpful.

Something like "$objectVar->property is uninitialized" will be
awesome.

Luigi Cardamone

--000000000000df23e50618e9e7bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On 18/05/2024 18:08, Rowan Tommins [IMSoP=
] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.php@rwec.co.uk</a>&gt; =
wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In my opinion - and I stress that others may not share this opinion - <br>
the entire concept of &quot;uninitialized properties&quot; is a wart on the=
 <br>
language, which we should be doing our best to eliminate, not adding <br>
more features around it.<br>
<br>
As a bit of background, the concept was created when typed properties <br>
were being added, to handle a limitation of the language: given the <br>
declaration &quot;public Foo $prop;&quot; there is no way to specify an ini=
tial <br>
value which meets the type constraint. For nullable properties, you can <br=
>
write &quot;public ?Foo $prop=3Dnull;&quot; but since PHP (thankfully) dist=
inguishes <br>
nullable and non-nullable types, you can&#39;t write &quot;public Foo $prop=
=3Dnull;&quot;<br>
<br>
Some languages, e.g. Swift, require that all properties are initialised <br=
>
before the constructor returns, but retrofitting this to PHP was <br>
considered impractical, so instead it was left to a run-time error: if <br>
you fail to initialise a property, you will get an error trying to <br>
access it.<br>
<br>
To track that, the engine has to record a special state, but assigning a <b=
r>
meaning to that error state is a bit like using exceptions for flow <br>
control. It would be more in keeping with the original purpose to have <br>
an object_is_valid() function, which returned false if *any* property <br>
had not been initialised to a valid value.<br>
<br>
<br>
PHP actually has a bewildering variety of such special states. In a <br>
different compromise added at the same time, calling unset() on a typed <br=
>
property puts it into a *separate* state where magic __get and __set are <b=
r>
called, which they are not if the property has simply not yet been <br>
assigned, e.g. <a href=3D"https://3v4l.org/C7rIF" rel=3D"noreferrer" target=
=3D"_blank">https://3v4l.org/C7rIF</a><br>
<br>
I have always found this a mess. If a property says it is of type <br>
&quot;?int&quot;, I want to know that it will always be an integer or null,=
 not <br>
&quot;int or null or uninitialised or unset&quot;. If it needs more than on=
e <br>
non-integer state, that should be specified in the type system, e.g. <br>
&quot;int|NotApplicable|NotSpecified|NotLoaded&quot;.<br>
<br></blockquote><div><br></div><div>I get your point. Now I see &quot;unin=
itialised&quot; as a dangerous thing.<br>Unfortunately this state exists an=
d I don&#39;t see any general way to<br>avoid objects with these properties=
. Fighting the &quot;uninitialised&quot; is<br>something big that we may tr=
y to discuss in another thread.<br>We have to deal with this state and a sy=
ntax to reliably check<br>those invalid properties will be helpful.<br><br>=
Something like &quot;$objectVar-&gt;property is uninitialized&quot; will be=
<br>awesome.<br><br>Luigi Cardamone</div></div></div>

--000000000000df23e50618e9e7bf--