Re: [RFC] [VOTE] Typed properties v2
| From: | Rowan Collins | Date: | Wed, 19 Sep 2018 21:46:49 +0000 |
| Subject: | Re: [RFC] [VOTE] Typed properties v2 | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-103190@lists.php.net to get a copy of this message | ||
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]