On 3/22/16 11:25 AM, Andreas Heigl wrote:
Am 22.03.2016 um 15:56 schrieb Larry Garfield <la...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
