On Wed, Sep 19, 2018 at 11:46 PM Rowan Collins <rowan.coll...@gmail.com>
wrote:
> On 19/09/2018 22:30, Marco Pivetta wrote:
> >
> > At least the approach without nullable properties will lead to a
> > Throwable when a read is attempted on an uninitialized object, which
> > is still better than nullability checks all over the place.
>
>
> Is it? Doesn't it just mean writing this:
>
> try {
> someFunction($object->propertyThatClaimsToBeNonNullable);
> } catch ( TypeError $e ) {
> ...
> }
>
> Instead of this:
>
> if ( ! is_null($object->propertyThatClaimsToBeNonNullable) ) {
> someFunction($object->propertyThatClaimsToBeNonNullable);
> } else {
> ...
> }
>
> For that matter, all I need to do is define someFunction as taking a
> non-nullable parameter, and I get the TypeError either way.
>
> Surely the point of a non-nullable property shouldn't be "it gives a
> slightly different error if it's not set", it should be "you don't have
> to worry about this not being set, because the language will enforce
> that somewhere". (And to cover your last point, that somewhere doesn't
> need to be the constructor, if requiring that is really such a big
> problem.)
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
That's what static analysis is for (see a bit above).
Sadly, static analysis doesn't really fit the engine out of the box, as PHP
is a bit too dynamic for that, and it doesn't really consider cross-file
declared symbols anyway.
Still, tools like PHPStan or Psalm can easily aid with that.
Also, there are scenarios (discussed in typed properties v1) that make the
uninitialized state actually favorable (every serializer ever, like every
one, really).
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
