In a new post on his blog Timothy Boronczyk has a recommendation for developers working in PHP with databases that have a "fetch object" method - use it correctly or avoid it all together.

Lately I'm finding a lot of instances of the mysql_fetch_object() function being used in a particular codebase I help maintain. Unfortunately, I've yet to see it used correctly. It always seems to be used to retrieve a stdClass object from a query result where mysql_fetch_array() or mysql_fetch_assoc() would be the more appropriate choice.

Most of his complaint is that, despite pulling out the data as an object, most scripts continue to use it like you would an array, looping over it. There's extra overhead generated from the object creation that could cause issues, especially with large return data sets.

The best advice I can offer is to educate yourself and others how the function should be used so its abuse isn't perpetuated. Then, be cautious when using mysql_fetch_object() correctly and understand the process it follows to create and return an object. If not for yourself, then do it for the kittens.

Lorna Mitchell has a quick reminder about an issue in the new joind.in API version - everything was being returned as strings, even integers.

A few weeks later (my inbox is a black hole and it takes a while to process these things) I fell over a throwaway comment to an undocumented constant JSON_NUMERIC_CHECK, and I added the constant name to my todo list. In the time it took for me to actually get around to googling for this, some wonderful person updated the PHP manual page (this is why I love PHP) to include it as a documented option, and someone else had added a user contributed note about using it.

This option, JSON_NUMERIC_CHECK, tells the json_encode function to property consider numbers in its encoding process. It applies globally, so if there's an instance where you don't want something assigned as a number, you might need to go with another, more flexible JSON encoding option. You can find information about this and other possible options json_encode can take on its manual page.

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.

Brian Swan has a new post to his blog today looking at one of the connection options for the SQL Server driver in PHP - the "ReturnDatesAsStrings" setting that can make handling date and time information simpler for PHP.

This is short post to address a frustration I've seen mentioned on Twitter and in forums a lot: By default, the SQL Server Driver for PHP returns datetime columns as PHP DateTime objects, not strings. This can be especially frustrating if you are not aware of the ReturnDatesAsStrings connection option. By simply setting this option to 1 (or true) when you connect to the server, datetime columns will be returned as strings.

He includes some sample code showing how to use the setting (as a part of the settings array passed in to sqlsrv_connect) and the resulting array key from the fetched results on his sample table. This just gives you one more option for handling dates in your SQL Server-based application, especially if you don't need the full DateTIme object's functionality.

Jani Hartikainen poses an interesting question on his blog today - is it more correct for a function, having failed at its job, to return a value of throw an exception.

You have created a nice, well written function, but you realize you forgot something: The failure case. What should a function do when it fails? There are two schools for this - the "throw an exception" school and the "return an error value" school. But which of these is the correct approach?

He suggests that this debate has stuck around from the time when there weren't exceptions in several popular programming languages and that returning the value was the only valid way. He touches on what an exception condition is (with a few code examples) and situations where each choice might be the right way to go.

php|architect has resurrected their podcast after quite a while to bring you the latest "news, opinion and pure, unadulterated PHP gossip" for your listening pleasure.

We're proud to announce that our ever-so-popular podcast is back on the air after a long hiatus'"in fact, we've got a brand-new format, a brand-new theme song...and even a brand new voice guy (but we could only afford him for the intro, so you're stuck with Marco's hypernasal voice and Super Mario-like accent for the rest of the show).

In this new episode Marco, Beth, Keith and Davey talk about the "PHP vs. ASP" debate, SXSW, PHP 5.3 and what's coming up in the latest php|architect issue. You can download the mp3 or add the feed to your reader to get the latest episodes as soon as they're released.

DevShed has posted the next in their "Introduction to CodeIgniter" series - this new tutorial about returning strings back from the views of your application.

Speaking more specifically, it's possible to feed the "$this->load->view()" method of CI a third Boolean parameter, to return the contents of a view to calling code after the view has been parsed. This is a handy variation of the method demonstrated in the previous article, and in this tutorial I'll be taking a close look at it, so you can grasp its underlying logic.

This technique could be useful when you want to render a certain block of code but don't want the application to have to reparse and rerender it. Pass the information to one view call, return the output back into a variable and push that back out into a main view any number of times.

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.

In a new entry Knut Urdalen looks at something that some PHP developers might have forgotten about - the return value of the include statement.

PHP never stops surprising me. I just found out that you're able to return values from the inclusion statements (require, require_once, include and include_once) through an example of Zend_Config.

His example puts an array of values inside the include file with a return statement. This script is included from another and, because of the return, the array data is passed back out into a waiting variable set equal to the include statement.

Patrick Allaert has made this recent post to his blog looking at something that a large group of PHP developers seem to forget about - readable PHP code. Specifically, he mentions the "return as soon as possible" mentality.

This is the first article of a series I will dedicate to tips to write PHP code that is easier to maintain, review, refactor,... These tips may be applied for other languages but are mainly focused on PHP. The first one could be entitled as "return as soon as possible.

He compares a code example - simplifying multiple if/elses, replacing the need for multiple nested evaluations that make the code harder to read. Check out the before and after to see how it helps the flow.