On TheCodingMachine.io there's a tutorial posted by David Négrier covering an interesting idea when handling "falseness" in your PHP application - throwing exceptions rather than returning false. In this case, he introduces the "safe" library to help make this easier.

At TheCodingMachine, we are huge fans of PHPStan. PHPStan is an open-source static analysis tool for your PHP code. [...] PHPStan has this notion of "levels" and we strive on each of our projects to reach "level 7" (the maximum level). But PHPStan is constantly improving, and reaching level 7 becomes harder and harder as the tool becomes more strict (this is a good thing!).

The post includes an example of this increasing strictness, showing how a more recent check looks at a file_get_contents call and ensures all possible return values are evaluated (it returns false when it errors). They refactor the code example to more correctly check for this, but losing some of the "expressiveness". The tutorial then spends some time talking about the history of PHP and why things return false rather than throw exceptions on error. It covers some of the basics of how the safe library works and a PHPStan extension that can help find places that need to be wrapped by "safe" to throw exceptions when false is returned.

In the latest episode of the Free the Geek podcast host Matthew Setter covers a few different topics including ones that's "quite dear to him", false perceptions (and how to get rid of them).

There’s no guests in this episode. Instead I explore a range of topics, including one quite dear to me - how we can build up preconceptions of what other people think of us.

I explore this and consider how false preconceptions can hinder us both personally and in our careers. With the exploration done, I throw down a challenge to get over them and see life, and see other people as they really are - not how we think they might be.

He also talks about his newest "toy" for recording while on the road and briefly about the Zend Expressive framework. You can listen to this latest episode either through the in-page audio player or by downloading the mp3 directly for listening offline. If you enjoy the episode, be sure to browse the archives, subscribe to their feed or follow them on Twitter for updates when the latest episodes are released.

Kevin Schroeder has a quick new post about using dependency injection in Zend Framework 2 applications using multiple object instances.

When you work with the ZF2 Dependency Injection Container (DiC) when you make multiple requests for an instance of an object you will get the same object back each time. [...] But what if you want the injection benefits of the DiC but don’t want to share the object? Use the DiC’s newInstance method instead with the third parameter being false.

He includes code examples of requesting the object both ways - the usual way that returns the same object and the alternative that passes in a "false" value, complete with a debug output of each object proving they're different.

Dan Horrigan has a new post to his blog talking about the value of null - a quick summary about when and where null should be used. Null's a value too, after all...

Let me start off by saying this article is about PHP and PHP alone. Other languages handle this sort of thing differently (and better). In PHP many people (and a few frameworks) return FALSE from methods when the requested value does not exist. However, I am here to tell you that if you do this, you are doing it wrong. Plain and Simple.

In his opinion, "false" is definitely not the same thing as "null" because "null" is technically the absence of a value, not a "not true" value like "false" is. He illustrates with a simple use case of a class that has methods returning various values.

Andrei Zmievski has written a new post about a new extension he's worked up (out of curiosity for the technology) - the pecl/bloomy extension.

A Bloom filter is a probabilistic data structure that can be used to answer a simple question, is the given element a member of a set? Now, this question can be answered via other means, such as hash table or binary search trees. But the thing about Bloom filters is that they are incredibly space-efficient when the number of potential elements in the set is large.

The filters allow false positives with a defined error rate - it gives the "yes" or "no" answer based on the content and you, the developer, decide if that answer falls within a rate that's okay for you and your app. The filters also take the same amount of time to look up items no matter how many are in the set.

He includes an example of the extension in use - defining the number of elements, the false positive allowance and adding/searching data and how the responses would come back from the checks.

Davey Shafik has taken a look at return values and keeping them standard when handing them back from the results of a database query.

In #phpc we recently had a discussion about function return values; specifically from database queries. I’m going to go on a (admittedly, rather sturdy looking) limb and say this applies to pretty much any function that returns from a data resource, not just a database .

His personal preference is to return the results data if there's matching information but to return a false value if there is an error/not results were found. He includes a snippet of example code to show the structure he's talking about. Some of the comments on the post mention things like exception handling, other similar methods other developers use and the use of nulls.

Felix Geisendorfer has come across something interesting in his coding - an issue where false might not be false in the right situation.

So far I've always thought false would evaluate to 0 when used in a computational context. Turns out that this isn't always the case.

His code example tries to check is a false value is greater than or equal to a negative number. The result, however (despite the thinking that false is a zero value) turns out to be false.

I randomly stumbled upon this when arguing with Mariano today if setting Model::recursive to 'false' has the same effect as setting it to '-1'. Turns out that cake uses a statement like this: if ($recursive > -1) in the core which in turn makes -1 and false do exactly the same thing.

Felix Geisendorfer has come across something interesting in his coding - an issue where false might not be false in the right situation.

So far I've always thought false would evaluate to 0 when used in a computational context. Turns out that this isn't always the case.

His code example tries to check is a false value is greater than or equal to a negative number. The result, however (despite the thinking that false is a zero value) turns out to be false.

I randomly stumbled upon this when arguing with Mariano today if setting Model::recursive to 'false' has the same effect as setting it to '-1'. Turns out that cake uses a statement like this: if ($recursive > -1) in the core which in turn makes -1 and false do exactly the same thing.

Tiffany Brown has posted an update to her look into is_numeric versus ctype_digit today, mentioning an issue she came across when testing based on the differences she found in her previous posting.

Just a quick follow-up to my post on is_numeric vs. ctype_digit. There is one quirk with ctype_digit that may affect your choice about whether to use it.

When the string in question is empty, ctype_digit returns TRUE. However, when it is null, ctype_digit will return FALSE.

She includes code to illustrate, noting the return of each function.

Tiffany Brown has posted an update to her look into is_numeric versus ctype_digit today, mentioning an issue she came across when testing based on the differences she found in her previous posting.

Just a quick follow-up to my post on is_numeric vs. ctype_digit. There is one quirk with ctype_digit that may affect your choice about whether to use it.

When the string in question is empty, ctype_digit returns TRUE. However, when it is null, ctype_digit will return FALSE.

She includes code to illustrate, noting the return of each function.