Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102922
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 64.147.123.21 cause and error)
To: internals@lists.php.net
Date: Thu, 19 Jul 2018 15:46:48 -0500
Message-ID: <4214843.pdQrXugUH7@vulcan>
In-Reply-To: <CALKiJKrt0NwUx2BWJRPWPtG5_znM4ttKtzKXLV7uCQ4yGWDkcg@mail.gmail.com>
References: <8916EC21-D368-40F8-9ABD-CE0C04A73539@gmail.com> <c2ecadcb-0c29-6cdc-fdde-e33bd53d5a79@gmx.de> <CALKiJKrt0NwUx2BWJRPWPtG5_znM4ttKtzKXLV7uCQ4yGWDkcg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1854010.PeuLDRBHqX"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] Non-nullable properties
From: larry@garfieldtech.com (Larry Garfield)

--nextPart1854010.PeuLDRBHqX
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Thursday, July 19, 2018 10:01:58 AM CDT Rowan Collins wrote:
> On 19 July 2018 at 15:20, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> > It seems to me that either of these proposals would render the lazy
> > initialization pattern outlined in the =E2=80=9COverloaded Properties=
=E2=80=9D
> > section[1] invalid.
> >=20
> > [1] <https://wiki.php.net/rfc/typed_properties_v2#overloaded_properties>
>=20
> Hm, I guess I didn't read that section carefully enough.
>=20
> It strikes me that that entire code pattern is a hack due to lack of
> property accessors, and it seems a shame to reduce the usefulness of the
> language's type system just to support it.
>=20
> From the responses on this thread, I get the feeling I'm in the minority,
> but it still feels utterly wrong to me that a property marked as
> non-nullable offers no guarantee at all that it will actually hold a valid
> value.
>=20
> Regards,

I get the sense that it should be treated as a bug in the implementing code=
,=20
not calling code.  That is, given:

class Foo {
  public Bar $bar;
}

If you call (new Foo)->bar and get a type error, you should not add null=20
checks but walk over to the Foo author's desk and slap them upside the head=
=2E =20
(Aka, file a bug report.)

I can see the value of punting there, and it's hardly the first time PHP ha=
s=20
punted on something in that fashion, but I agree that the whole point of su=
ch=20
checks is to make sure that the Foo author *can't make that mistake in the=
=20
first place*.  That's rather the point of all type hints in PHP.  The more=
=20
errors are compile time errors the better.

I wouldn't mind dropping that overloading behavior if it gave us more=20
guarantees about property validity.

=2D-Larry Garfield
--nextPart1854010.PeuLDRBHqX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAltQ+LgACgkQ4MMKwDFx
YXdApQgAkuQ3GWBiklCH2o970eNAcmtVOZofBH2U/E7wXAIolF4Pnb+9hsA9Ix5E
NyYGLPMYXo6NC8aBKF3UyYXbeGhq9fNRtEtaJThsfu40vAvvxfmDWrbcHhU2EQa+
8Ke6rV18sONWeM3V7VT3hTIGK8M7LHV2gv4xlslYKcgw8QI9WrTsj7LWHHBO8dda
0HbsJShV4SufvAP74KRaUAUOcv8/kBBtOWfoZ7jl0OUDrlCfltW2qQlW8FfbQUgJ
F+i36EG9VPtVXetbPqfQ54JBjHII0kW3dnfxCtjOx0cuinG0bTT9peyGg6e7Ii3+
Kwq4EHerbGsVoL6ZRuDci8MEeQyl+w==
=mJGp
-----END PGP SIGNATURE-----

--nextPart1854010.PeuLDRBHqX--