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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
