Re: Non-nullable properties

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 “Overloaded Properties” > > section[1] invalid. > > > > [1] > > <https://wiki.php.net/rfc/typed_properties_v2#overloaded_properties> > > Hm, I guess I didn't read that section carefully enough. > > 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. > > 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. > > Regards, I get the sense that it should be treated as a bug in the implementing code, 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 checks but walk over to the Foo author's desk and slap them upside the head. (Aka, file a bug report.) I can see the value of punting there, and it's hardly the first time PHP has punted on something in that fashion, but I agree that the whole point of such checks is to make sure that the Foo author *can't make that mistake in the first place*. That's rather the point of all type hints in PHP. The more errors are compile time errors the better. I wouldn't mind dropping that overloading behavior if it gave us more guarantees about property validity. --Larry Garfield

Attachment: [application/pgp-signature] This is a digitally signed message part. signature.asc