On 16 July 2018 13:00:57 BST, Dan Ackroyd <[email protected]> wrote:
>On 16 July 2018 at 09:43, Rowan Collins <[email protected]>
>wrote:
>
>> There's no contradiction here; throwing an error when a
>> property is *read* is not the same as enforcing that it always has a
>valid value.
>
>That's true, but claiming the RFC just 'trusts' the users to
>initialise them is a miss-representation of the RFC to me. The RFC
>catches the mistake if the programmer fails to initialise the variable
>then reads from it.
Perhaps a better wording is that it requires one user to trust another user:
the mistake that leads to an unitialized property is the responsibility of the
author of the class, but the error only appears when the object is used, which
could be in a completely different library.
>> If not, the object created would not be fully initialised,
>
>This is always going to be the case, unless you're proposing to
>deprecate ReflectionClass::newInstanceWithoutConstructor .... which is
>going to break a huge number of applications.
It only needs to be banned (or modified) *for classes which claim their
properties are non-nullable*. Or, don't introduce non-nullable properties,
because they can't actually be enforced.
> For me
>it is the equivalent of this:
>
>function foo() : int {
> return "five";
>}
>
>This gives an error when the code is run, not when the code is
>compiled
It's not about run-time versus compile-time, it's about when the error is
raised. In this case, it's raised when the return statement is executed. The
equivalent to the proposed behaviour would be this:
function foo() : int {
return "five";
}
$foo = foo(); // runs OK, but marks the variable as invalid
// ... Many lines of code later
// $foo has not been touched so should be an integer
$bar = $foo + 1; // Error! Sorry, somebody messed up a return value somewhere,
it's now up to you to figure out where
>That would only be a problem in production if you don't run that code
>at all in development or in test....
If you are going to write tests to see if all your variables are being
initialized correctly, then you don't need non-nullable type hints, you can
just assertNotNull on each property.
But again, the user writing those tests is not the user relying on them. You
are asking users of a library to trust that the library has appropriate tests.
Regards,
--
Rowan Collins
[IMSoP]
