Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92336
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
To: internals@lists.php.net
References: <D33531D4.6D3F3%fsb@thefsb.org>
 <CAFMT4NqGa=mKUksczpe6HepjM1Wthsw9dY7dX3JBWO9xB-FLJA@mail.gmail.com>
 <D3357498.6D41E%fsb@thefsb.org>
 <CAFMT4NrN=q1ZBUXGBPquFTVVaJpoHfbhTDKU2LMZY1C5tu4FKg@mail.gmail.com>
 <D335A5AA.6D579%fsb@thefsb.org> <57103A46.6040803@garfieldtech.com>
 <CAFMT4NpOCf3VON01_3n4xMKVOhEVNL-CsRm5gYOgogEnwt=XvQ@mail.gmail.com>
 <5710BA79.5060108@lsces.co.uk>
Message-ID: <57110DC5.8000007@garfieldtech.com>
Date: Fri, 15 Apr 2016 10:50:29 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <5710BA79.5060108@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Nullable Return Type Declaration
From: larry@garfieldtech.com (Larry Garfield)

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