Re: [RFC][Vote] Typed Properties

From: Date: Thu, 26 May 2016 17:20:20 +0000
Subject: Re: [RFC][Vote] Typed Properties
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-93579@lists.php.net to get a copy of this message
On 26/05/2016 17:57, Fleshgrinder wrote:
On 5/26/2016 6:50 PM, Rowan Collins wrote:
As I'm sure has already been pointed out (I haven't followed the whole thread) this defeats a large advantage of typed properties - I now can't read from the property without checking if it's null, so I can't do this: class O { public \DateTimeImmutable $d; } echo (new O)->d->format('Y-m-d H:i:s'); There's no ? on the type def, so I ought to be able to trust the type. A TypeError makes more sense here, because it is a programming error for it to be in this state.
That is exactly what Stanislav raised too. I really have no idea how we should prevent this from happening and honestly think we shouldn't. Your construct will result in a fatal error (also known as NullPointerException to some, *evil-laughter*) anyways preceded by an E_NOTICE that tells you that your property is not defined. I am of course open for ideas but emitting another kind of fatal error does not really make things better imho.
I think the difference is the emphasis of whose responsibility it is to fix it: a TypeError confirms that the error is in the O class for exposing an incorrectly typed property; a NullPointerException, as you put it, makes it my fault for trusting the class. Or to put it a different way, is the error in the first arrow (accessing "->d") or the second one (de-referencing "d->"). At the end of the day, all the type notations being added to PHP are just assertions anyway. So the same could be said of this: function foo(\DateTime $d) { echo $d->format('Y-m-d H:i:s'); } foo(null); If this didn't throw an error at "foo(null)", it would throw an error at "$d->format". Regards, -- Rowan Collins [IMSoP]

« previous php.internals (#93579) next »