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.
While a monad sounds cool, it doesn't seem like the necessary language
infrastructure is there for it at the moment.
[1] My most recent talk that has a section on returns:
https://youtu.be/rWDY4-LJils?t=2m38s (that's where the return type
segment starts)
Slides:
https://www.palantir.net/presentations/midcamp2016-php7/
--
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
