Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91850
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain heigl.org from 195.191.240.18 cause and error)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
In-Reply-To: <56F15D31.5070405@garfieldtech.com>
Date: Tue, 22 Mar 2016 17:25:28 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <C67770FC-F8E9-4667-89CC-4F6941403F66@heigl.org>
References: <CANp8VMVcZU3VCbNRrngvsP8JxJ0Hk1ZmbH5zb9D30dBea1O1hw@mail.gmail.com> <2070425.mznTmPgxij@mcmic-probook> <56F15D31.5070405@garfieldtech.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] RFC Proposal: Maybe monad and execution time polymorphic methods
From: andreas@heigl.org (Andreas Heigl)



> Am 22.03.2016 um 15:56 schrieb Larry Garfield <larry@garfieldtech.com>:
>=20
>> On 3/21/16 10:23 PM, C=C3=B4me Chilliet wrote:
>> Le lundi 21 mars 2016, 17:04:30 Facundo Martinez Correa a =C3=A9crit :
>>> But then I realized the problem. There
>>> are many times where we need uncertainty. Code is a reflection of realit=
y,
>>> 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 fo=
r
>>> 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 exist=
s?
>>> That it will exist? Should I allow it? Is it a good value? I for sure do=
n't
>>> know. And in my experience, I have used it for many of those cases. And i=
n
>>> 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=E2=80=99t, maybe it=
 should throw an Exception.
>> Just wanted to point out it can be a good alternative to returning NULL f=
or error handling.
>>=20
>> C=C3=B4me
>=20
> In the PHP 7 and typing presentations I've been giving[1], I've advocated e=
ither:
>=20
> 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 equivalen=
t of 0/empty string.

When code expects a user-object but can't get one it'll break. Throwing an e=
xception makes it easy to react to that. But when the code has to check whet=
her that's a mocked user object or a real user object it's about as good as r=
eturning null or eliminating the return type altogether as you have to build=
 the code around that returned value you can't really use.=20

So in my opinion either return a proper object/type or throw an exception.

My 2 cent

Cheers

Andreas
>=20
> While a monad sounds cool, it doesn't seem like the necessary language inf=
rastructure is there for it at the moment.
>=20
> [1] My most recent talk that has a section on returns:
> https://youtu.be/rWDY4-LJils?t=3D2m38s (that's where the return type segme=
nt starts)
> Slides:
>=20
> https://www.palantir.net/presentations/midcamp2016-php7/
>=20
> --=20
> --Larry Garfield
>=20
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20