These don't really need explicit tests in most cases, but rather static
analysis (currently happening via docblocks). Static analysis tools like
vimeo/psalm already pick this up.
I'd even be happy to get type hints that only have effect on
`ReflectionProperty#getType()` as a massive improvement over the current
situation we've monkey-patched us into, but the patch is indeed consistent
with PHP's current state.
On Mon, 16 Jul 2018, 15:24 Rowan Collins, <rowan.coll...@gmail.com> wrote:
> On 16 July 2018 13:00:57 BST, Dan Ackroyd <dan...@basereality.com> wrote:
> >On 16 July 2018 at 09:43, Rowan Collins <rowan.coll...@gmail.com>
> >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]
