Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102849
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.67 as permitted sender)
Date: Mon, 16 Jul 2018 14:23:43 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CA+kxMuQ4FMS5Ob1aoe2mNLYokYht64Bax7k8oKTa60kjMpz+4w@mail.gmail.com>
References: <8916EC21-D368-40F8-9ABD-CE0C04A73539@gmail.com> <CA+kxMuRBa7YFvH3sW4aALv43vumsXthfdNkNXe=_DU7dzwUA2w@mail.gmail.com> <0AA3251E-A0D8-492E-AEAC-3B2FBBFDB944@gmail.com> <CA+kxMuQ4FMS5Ob1aoe2mNLYokYht64Bax7k8oKTa60kjMpz+4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----E6SDFEVXG8HHHHWCQ7FWBK9DM9TTIG"
Content-Transfer-Encoding: 7bit
To: Dan Ackroyd <danack@basereality.com>
CC: PHP internals <internals@lists.php.net>
Message-ID: <F0ECBE85-8D8F-4EF5-88C0-A4B7E94E4866@gmail.com>
Subject: Re: [PHP-DEV] Non-nullable properties
From: rowan.collins@gmail.com (Rowan Collins)

------E6SDFEVXG8HHHHWCQ7FWBK9DM9TTIG
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 16 July 2018 13:00:57 BST, Dan Ackroyd <danack@basereality=2Ecom> wrote:
>On 16 July 2018 at 09:43, Rowan Collins <rowan=2Ecollins@gmail=2Ecom>
>wrote:
>
>> There's no contradiction here; throwing an error when a
>> property is *read* is not the same as enforcing that it always has a
>valid value=2E
>
>That's true, but claiming the RFC just 'trusts' the users to
>initialise them is a miss-representation of the RFC to me=2E The RFC
>catches the mistake if the programmer fails to initialise the variable
>then reads from it=2E

Perhaps a better wording is that it requires one user to trust another use=
r: the mistake that leads to an unitialized property is the responsibility =
of the author of the class, but the error only appears when the object is u=
sed, which could be in a completely different library=2E



>> If not, the object created would not be fully initialised,
>
>This is always going to be the case, unless you're proposing to
>deprecate ReflectionClass::newInstanceWithoutConstructor =2E=2E=2E=2E whi=
ch is
>going to break a huge number of applications=2E

It only needs to be banned (or modified) *for classes which claim their pr=
operties are non-nullable*=2E Or, don't introduce non-nullable properties, =
because they can't actually be enforced=2E



> For me
>it is the equivalent of this:
>
>function foo() : int {
>   return "five";
>}
>
>This gives an error when the code is run, not when the code is
>compiled

It's not about run-time versus compile-time, it's about when the error is =
raised=2E In this case, it's raised when the return statement is executed=
=2E The equivalent to the proposed behaviour would be this:

function foo() : int {
   return "five";
}
$foo =3D foo(); // runs OK, but marks the variable as invalid
// =2E=2E=2E Many lines of code later
// $foo has not been touched so should be an integer
$bar =3D $foo + 1; // Error! Sorry, somebody messed up a return value some=
where, it's now up to you to figure out where



>That would only be a problem in production if you don't run that code
>at all in development or in test=2E=2E=2E=2E

If you are going to write tests to see if all your variables are being ini=
tialized correctly, then you don't need non-nullable type hints, you can ju=
st assertNotNull on each property=2E

But again, the user writing those tests is not the user relying on them=2E=
 You are asking users of a library to trust that the library has appropriat=
e tests=2E

Regards,
--=20
Rowan Collins
[IMSoP]
------E6SDFEVXG8HHHHWCQ7FWBK9DM9TTIG--