Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91851
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
To: internals@lists.php.net
References: <CANp8VMVcZU3VCbNRrngvsP8JxJ0Hk1ZmbH5zb9D30dBea1O1hw@mail.gmail.com>
 <2070425.mznTmPgxij@mcmic-probook> <56F15D31.5070405@garfieldtech.com>
 <C67770FC-F8E9-4667-89CC-4F6941403F66@heigl.org>
Message-ID: <56F17468.6010205@garfieldtech.com>
Date: Tue, 22 Mar 2016 11:35:52 -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: <C67770FC-F8E9-4667-89CC-4F6941403F66@heigl.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC Proposal: Maybe monad and execution time
 polymorphic methods
From: larry@garfieldtech.com (Larry Garfield)

On 3/22/16 11:25 AM, Andreas Heigl wrote:
>
>> Am 22.03.2016 um 15:56 schrieb Larry Garfield <larry@garfieldtech.com>:
>>
>>> On 3/21/16 10:23 PM, Côme Chilliet wrote:
>>> Le lundi 21 mars 2016, 17:04:30 Facundo Martinez Correa a écrit :
>>>> But then I realized the problem. There
>>>> are many times where we need uncertainty. Code is a reflection of reality,
>>>> and as such, it must reflect uncertainty. NULL is a good enough way to
>>>> express nonexistence, albeit a bad one. We have been using it in code for
>>>> years, but it is also used to say many things. Things that cause
>>>> uncertainty in the code. I receive a null, does it mean it doesn't exists?
>>>> That it will exist? Should I allow it? Is it a good value? I for sure don't
>>>> know. And in my experience, I have used it for many of those cases. And in
>>>> many situations that I'm not proud of, all of them at the same time.
>>> If your function is supposed to return a User and can’t, maybe it should throw an Exception.
>>> Just wanted to point out it can be a good alternative to returning NULL for error handling.
>>>
>>> Côme
>> In the PHP 7 and typing presentations I've been giving[1], I've advocated either:
>>
>> 1) Throw an exception if the rest of the code is going to break anyway.
>> 2) Define an empty object with matching interface if you want an equivalent of 0/empty string.
> When code expects a user-object but can't get one it'll break. Throwing an exception makes it easy to react to that. But when the code has to check whether that's a mocked user object or a real user object it's about as good as returning null or eliminating the return type altogether as you have to build the code around that returned value you can't really use.
>
> So in my opinion either return a proper object/type or throw an exception.

An "empty" object as I describe it isn't really a proper empty object 
unless it does satisfy the type and interface, such that you don't need 
special handling for it.  The example I use in the slides is an Address 
object, with AddressInterface, whose "empty" implementation just has 
empty strings for all the various parts of it.  That will work in some 
use cases but not others.  It's up to the developer to determine if a 
reasonable empty object would work in their situation or not.  If it 
doesn't, I agree, an exception is the answer.

In any event, it sounds like a native monad won't work well in PHP so 
we're now drifting off topic. :-)

-- 
--Larry Garfield