As PHP developers, dealing with the "helpful" automatic type shifting the language performs can sometimes be challenging. It can lead to some interesting situations like the one Freek van Der Herten has posted about where something that seems "empty" actually isn't.

Recently when I was working on a project I got some strange results when using the empty function. That's really odd [that the result was a string and "empty" when a value was set]. How can a variable hold a string and be empty at the same time?

He includes a few other tests on the same object and firstName property using other "empty" checks with isset and is_null. Those behaved as expected so he started to look more into the class the object is based on. In the class values/properties are returned via magic methods, not direct functions. In the case of empty, this fetching isn't interpreted prior to the check and the result appears "empty". To fix the issue, he recommends implementing an __isset magic method that will then get called to ensure the value is actually set before fetching it.

Loïc Faugeron has posted another in his series of "Ultimate Developer Guides" for a component of the Symfony framework. In the latest part of the series, he looks at the Skeleton component.

In this guide we've explored the main standalone libraries (also known as "Components") provided by Symfony to help us build applications: HTTP Kernel and HTTP Foundation, Event Dispatcher, Routing and YAML, Dependency Injection and Console. We've also seen how HttpKernel enabled reusable code with Bundles.

In this article, we're going to have a closer look at how to organise our applications directory tree.

He shows how to create a new project with the "empty edition", a skeleton for creating a basic Symfony framework with some of the basic boilerplate already in place. He shows the resulting directory tree and creates a new AppBundle for his new development. Initially he put the bundle under the main directory so he then shows how to decouple this and move bundles and libraries out into a src/ directory outside of the main application directory in the skeleton.

Rob Allen has a post to his site to help clear up some confusion with how the ZendInput component handles "empty" between the required, allow_empty and continue_if_empty logic.

These settings define what happens when you try to validate an empty value for a given input. For ZendInput, empty means exactly equal to null, an empty string or an empty array.

He starts by outlining each of the three settings including both their default settings and its intent. He gets into a bit more detail on continue_if_empty as it has additional logic that depends on the results of the other two settings. He includes a small test application that cycles through a set of values and evaluates them through a ZendInput instance. The output is also included in the post so you can verify your system is seeing the same evaluation results.

Larry Garfield has posted some of his thoughts on return values and reminds you about consistent return types, regardless of the result.

Earlier today, I posted a brief tweet (isn't that redundant?) about return values in PHP (or really, any language). Originally it was about return values from functions (such an exciting topic, I know), but it ended up generating a fair bit of lively conversation, as well as a patch against Drupal 8. So lively, in fact, that I think it deserves more than 140 characters.

He proposes a new rule of thumb: "If your function returns a collection, its null value return must also be a collection." A more broad version of this might be: "make your return types consistent." It's all about predictability and the contracts you have between different parts of your code. If a user calls your method expecting to be able to loop over the results, they'll be disappointed with a "false". He talks some about using and throwing exceptions more effectively for error handling and answers several "but wait..." arguments for his return strategy.

If you've ever been bothered by those pesky NOTICEs when running your code, you know that you can wrap evaluations or check things with an empty or isset call to make them go away. Brandon Savage has a new post that can help you decide which one to use when, though.

As developers, we want to develop code that never emits notices or warnings, and PHP gets a bit antsy when we develop code that utilizes uninitialized variables. Lucky for us, PHP makes it easy to test for these variables without getting these notices. [...] PHP (like most languages) evaluates a logical argument left to right. For an AND condition, both conditions have to be true; PHP stops evaluating if it finds any condition untrue.

He suggests that the case to use isset() is more when you just want to use another check in the conditional but don't want to be bothered if the variable isn't there. A call to empty(), however, also evaluates the contents of the variable if it exists. Be careful, though - empty() returns false if the value of the variable is false - so take care in your use and always test scripts with multiple values.

Felix Geisendorfer has posted two new items to the Debuggable blog looking at suppressing errors in your applications - and no, that doesn't mean using the @ operator either.

As of late I am getting sick of some best practices I have taught myself. Never using the @-error suppressing operator quickly moving to the top of the list. Before you start crying out loud (I know you will), let me say this: I do not mean to encourage anybody to use the @-operator. Applying the practice herein introduced may result in permanent damage to your coding habits and could serve as a gateway behavior to writing shitty code.

He gives an example in the first post of a place where he failed to properly check to ensure an element existed before checking a element of it. The second post provides an interesting solution to the same problem - using empty on the element/subelement to check its existence.

In this new post to his blog, Brian Moon compares two things that, on the outside, might seem a lot alike but do have their differences under the hood - a null value and the isset function.

I am working with a newcomer to PHP and he asked me about setting a variable to null and how to check that. He had found some example or information that showed that setting a varaible equal to null would unset the variable. So, he was unclear if he could then reliably check if the variable was equal to null. Having avoided null like the plague in my years of PHP, I was not sure. So, I mocked up a quick script to see what the states of a variable are in relation to null.

His test verified that a variable, set equal to null will be found to be equal to null, will be set (isset) and will be found empty by PHP's empty

Jani Hartikainen has posted about three simple, but hard to find, mistakes that can cause you endless frustration if you're not looking in the right places.

Here's his list:

• Semicolon after a while - a small problem with big (infinitely looping) consequences)
• empty() and magic __get method - __get will hit first, then empty
• Missing semicolon after break or continue - a classic that can make switches and evaluations difficult to debug

Comments on the post include a few others: working with variables by reference, comparisons with == versus === and strpos finding the first character in a string.

On DevShed today, there's a new tutorial posted looking at two things that can cause headaches for PHP developers (especially when evaluating and comparing values) - nulls and empty strings.

Anyone who has programmed for any length of time has encountered the concepts of null and empty strings. They are not the same, and confusing the two can cause some serious problems. This article deals with these concepts in the context of PHP and MySQL.

They start with a bit of a quiz before getting into how to handle them correctly - making null "safe" and working with it correctly in a MySQL context. SQL statements and table structures are included for their examples.

Brian Moon has a "stupid PHP trick" posted to his blog today - normalizing SimpleXML data you've pulled in from just about any external source.

Anyhow, one annoying thing about SimpleXML has to do with caching. When using web services, we often cache the contents we get back. We were having a problem where we would get an error about a SimpleXML node not existing.

They were using memcache to store the information but came across problems when their code tried to use a (sometimes) empty tag. He gives two solutions - one using a recursive function that identifies the empty items and the other that encodes then decodes the object to and from JSON, keeping the values intact.