PHP has a function called
which can only return a boolean value, which is good at this point. The purpose of the function is to check if a variable "is empty" ...
You can check out it's documentation or try this example to see what is all considered as "empty".
echo 'empty(true):' . (empty(true) ? 'true': 'false') . PHP_EOL;
echo 'empty(false):' . (empty(false) ? 'true': 'false') . PHP_EOL;
echo 'empty(0):' . (empty(0) ? 'true': 'false') . PHP_EOL;
echo 'empty((float)0.0):' . (empty((float)0.0) ? 'true': 'false') . PHP_EOL;
echo 'empty(null):' . (empty(null) ? 'true': 'false') . PHP_EOL;
echo 'empty():' . (empty('') ? 'true': 'false') . PHP_EOL;
echo 'empty("foo"):' . (empty('foo') ? 'true': 'false') . PHP_EOL;
echo 'empty(object):' . (empty(new stdclass()) ? 'true': 'false') . PHP_EOL;
With 7.4.21 I'm getting this result:
And hopefully with other versions of #PHP
you get the same result. But if not, then there is the problem. Users can have a variety of versions installed, even those being marked as End-Of-Life (which as a software developer you should never support, get your system updated
, lazy arse!!!).
So do you want ...
1) Your coder relies on a PHP function that has a change of behavior (other returned result than before updating PHP)?
2) Don't/Can't update PHP and get stuck with a EOL version?
3) Or maybe rewrite it in a way that when an incompatible update happens you only have to change a little bit?
is maybe not changing so fast in the near future, but who knows? Surely you and me don't have a magic orb at home where you can see it coming ... LOL
For the last option, I had introduced
which does this exactly for you. It keeps your code easily upgradeable because you might only have to change that method (if properly used everywhere). But there is a drawback in Friendica's code:
- If a boolean is present in
(mixed type parameter of it), it simply returns it (even when it is
, so your code "thinks" that the record is found ...
- On successful retrieval of the record either an
can be present in
. So they both need to be checked individually.
What I found troubling (confusing) here is that why so many different types can be returned from the DAL (the class
is some kind of DAL) and not always a single result class, e.g.
which contains the whole result, how many records have been found or being affected and so on.
This is a WAY much cleaner approach and you are more object-oriented and not lesser. If it was me, I would rewrite the entire code of #Friendica
around this issue towards that class.
And if it was me, I would make sure that (no matter how important the table is) method invocations are correct, means e.g. no
for an id column or valid id number (you can always call
before!). And if this causes to much redundant queries, you can always cache the result and just return the cache instead.
Sure this increases memory footprint, that's the deal you have to make: More cache or more SQL queries.