On Thursday, July 19, 2018 10:01:58 AM CDT Rowan Collins wrote: > On 19 July 2018 at 15:20, Christoph M. Becker <cmbecke...@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
signature.asc
Description: This is a digitally signed message part.
