Re: [RFC] Nullable Return Type Declaration

On 4/15/16 4:55 AM, Lester Caine wrote:

On 15/04/16 05:22, Levi Morrison wrote:

Unless you like having is_null() scattered around your code in a hundred

places... I don't. :-)

You have lots of code instead in exception handling away fro the normal program flow?

[1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions --Larry Garfield

My point is that foo(bar(), $val) won't die because bar may return null. Bar is expected to return null sometimes. For example, let's consider an administrator page where they look up user information based on an identifier. The routine we'll use will have this signature:

     function get_user(string $id): User | Null;

It is possible for an identifier to not exist and this is not an error (database successfully returned no results). If there is no User data to display then it makes sense for the UI to present that differently. Thus it makes sense to pass that User | Null onto the code that will present it:

     $user_data = get_user($id);
     // ...
     $user_html = render_user_data($user_data);

In fact this is a common operation that is encountered in many code bases (I think every single one I've ever looked at).

That is a possible database type scenario, although on all of my systems, the 'guest' user will be accessed as a default which gives the default user data set. The main thing I see with the 'null is not needed' argument is that it instead relies on 'exception handling'? If I am scanning a file or reading a record set, at some point I hit the end, and in ALL my code base I get a null object rather than result object, be that reading and processing a file or a database feed. We have already had the complaints about file handling should give an exception when there is nothing left, but MY workflow keeps everything in line ... when the last record is processed we see the 'null' and progress to the next step in the process. There is nothing here that needs to involve throwing exceptions which may well be coded out of line with the main program flow and make debugging more difficult?

That there are a few small cases where PHP's current design makes NULL a reasonable sentinel value (custom iterators, fread() as you mention, etc.) does not mean that in most cases, returning ValueObject|Null is rude and abusive to users of your API. Yes, end-of-file is not an exceptional case so should not throw an exception. I completely agree there. But "user not found" I'd argue is. (Or rather, if it's not an exceptional case your data model is kinda broken to begin with, because why are you asking for a missing user?) Or you're better off having an "empty" value instead, such as an anonymous user object. That's still type safe. I'm not suggesting that we purge NULL from the language. That's impractical/impossible. I'm suggesting we shouldn't soften the type system added in 7.0, which discourages its use in most cases, as it should be. -- --Larry Garfield