{"id":1642,"date":"2016-03-05T18:40:48","date_gmt":"2016-03-05T17:40:48","guid":{"rendered":"https:\/\/www.entropywins.wtf\/blog\/?p=1642"},"modified":"2018-07-31T13:02:57","modified_gmt":"2018-07-31T12:02:57","slug":"missing-in-php7-nullable-return-types","status":"publish","type":"post","link":"https:\/\/www.entropywins.wtf\/blog\/2016\/03\/05\/missing-in-php7-nullable-return-types\/","title":{"rendered":"Missing in PHP7: Nullable return types"},"content":{"rendered":"

This is the fifth post in my Missing in PHP7 series<\/a>. The previous one is about Collections<\/a>. This is a short post, as there really is not much to explain or motivate.<\/p>\n

Nullable return types<\/strong><\/p>\n

As of PHP7, we have return types<\/a> at our disposal. Unfortunately, these have some annoying limits. One of them I described in my PHP Collections<\/a> blog post. Another is the lack of nullable return types. This blog post is about the latter.<\/p>\n

Take the following code<\/p>\n

class DoctrineKittenRepository implements KittenRepository {\n    \/**\n     * @param int $kittenId\n     * @return Kitten|null\n     *\/\n    public function getKittenById( int $kittenId ) {\n        try {\n            $kittenOrmEntity = $this->doctrineThing->gimmehStuff();\n        }\n        catch ( ORMException $ex ) {\n            return null;\n        }\n\n        if ( $kittenOrmEntity === null ) {\n            return null;\n        }\n\n        return $this->getKittenFromOrmObject( $kittenOrmEntity );\n    }\n\n    private function getKittenFromOrmObject( OrmKitten ): Kitten {\n        return new Kitten( \/* ... *\/ );\n    }\n}<\/pre>\n
This is a repository<\/a>, that obtains a kitten from the persistence in some manner (such as using Doctine ORM<\/a>). It then returns the kitten as an Entity part of the domain, in this case represented by the Kitten<\/code> class. As you can see, we’re using a return type hint for the getKittenFromOrmObject<\/code> private method. However for the public method, we’re prevented from using a return type hint, as it can also return null. This is really unfortunate, as we need to fall back to using documentation instead of code. The IDE I’m currently using, PhpStrom, manages to add salt to the wound by then requiring all parameters to also be present in the docblock if you don’t want to get any warnings about them not being there.<\/p>\n
It’d be very nice to be able to do<\/p>\n
public function getKittenById( int $kittenId ): Kitten|null {}<\/pre>\n
Or alternatively<\/p>\n
public function getKittenById( int $kittenId ): ?Kitten {}<\/pre>\n
After asking about this on Stack Overflow<\/a> several months ago, I found out that there is an RFC for nullable return type declarations<\/a>. Unfortunately this appears to not be going anywhere for now. A somewhat related RFC, one for introducing a void return type<\/a>, has on the other hand already been implemented and will land in PHP 7.1.<\/p>\n
Nullability in Java<\/strong><\/p>\n
I have not often worked with Java in the recent past, though when I did, I always ended up being surprised by it’s default nullability of types.<\/p>\n
void someStuff(Kitten kitten) {\n    if (someobject != null) {\n        kitten.doStuff();\n    }\n}<\/pre>\n
The caller of someStuff<\/code> can pass in null, which forces null checks in many places, be it like above, or in the form of a guard clause<\/a> that throw a type error. This is annoying, and indeed, the Clean Code book<\/a> even has a chapter on avoiding returning null.<\/p>\n
So not all is bad in PHP-land when it comes to nullability \ud83d\ude42<\/p>\n