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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
