On the Refulz.com blog there's a recent post introducing the __toString() magic method in PHP. This handy method allows you to define how to return an object when it's referenced as a string.

We started the study of PHP magic methods by learning about __get() magic method. [...] PHP is loosely typed language and same variable can be used or referred as string, number or object. The __toString() method is called when the code attempts to treat an object like a string. This function does not accept any arguments and should return a string.

Some quick code is included showing how it works - returning a combined string made from two private class properties when the object ($obj) is echoed out. They also show multiple ways of using the method in both pre- and post-PHP 5.2.

Nicolas Grekas has shared another tool that he's pulled out of his "Patchwork" framework to make it a stand-alone tool: the Patchwork-UTF8 helper that provides matching functions to those PHP already has for regular strings, but a little smarter to work with UTF8 correctly.

The PatchworkUtf8 class implements the quasi complete set of string functions that need UTF-8 grapheme clusters awareness. These functions are all static methods of the PatchworkUtf8 class. The best way to use them is to add a use PatchworkUtf8 as u; at the beginning of your files, then when UTF-8 awareness is required, prefix by u:: when calling them.

In the README for the tool he talks about the functions included in the current release that match PHP's string functions as well as some additional methods like "isUtf8", "bestFit" and "strtocasefold". It relies on the mbstring, iconv and intl extensions being installed, and if they aren't, it falls back to other functionality (list of those methods included).

In this new post to his blog Nikita Popov aims to dispel the popular micro-optimization myth of using single quotes over double quotes for a performance boost.

If there is one PHP related thing that I really hate, then it is definitely the Single Quotes Performance Myth. [...] Let's do a random Google search for "PHP single quotes performance": You will get many results telling you that single quotes are faster than double quotes and that string interpolation is much slower than string concatenation. Most of them advise to use single quotes and concatenation to improve the performance of your application. Let's be clear here: This is pointless.

He did some benchmarking of his own to see how the myth would hold up and, as it turns out, it doesn't - "There is none". His proof compares two strings, one normal single-quoted and the other a double-quoted, and the opcodes they generate. They end up exactly the same. Since it's the opcodes that matter, he recommends using something like APC if you're really worried about the performance. He also includes an example using the token_get_all function of PHP to see how fast the strings run through the lexer too (again, almost no difference).

As an added bonus, he also throws in a bit about string concatenation versus string interpolation with some benchmarking scripts and results of their own.

In this quick new post to his blog Mark Story talks about two new errors he ran across when upgrading his installation to PHP 5.4, both showing up under E_ALL.

I've been running the PHP5.4 RC builds for the last few months, and there are some interesting changes in the upcoming PHP release. On top of all the great new features coming in PHP5.4. After updating to PHP5.4-RC4, a few things that used to not trigger errors and silently do the wrong thing, now trigger notices or warnings.

The two he mentions deal with a new warning on illegal string offsets and the other about string offsets ("Notice: String offset cast occurred"). You can find out about more changes in the PHP 5.4 series in the various Changelogs for each Release Candidate and beta release.

On PHPMaster.com today James Appleyard has put tother a tutorial for the beginners out there about working with strings in PHP, using the huge list of built-in functions to work with your values.

PHP has a vast selection of built-in string handling functions that allow you to easily manipulate strings in almost any possible way. [...] There is no way I can cover every string function in one article, and besides, that is what the PHP manual is for! But what I will do is show how to work with some of the most commonly used string handling functions that you should know. After this, you'll be working with strings as well as any concert violinist!

He shows how to use functions to: change the case of string, remove extra whitespace, get the length, slicing them up and doing replacing on some certain characters. You can find more information on these and the complete list of string functions in PHP in the manual.

If you're new to the PHP language and are looking for the full scoop on working with the string datatype, look no further than this new post from Mrinmoy Ghoshal. It's an excellent (and quite complete) resource for just about everything involving strings in PHP.

A string is series of characters, where a character is the same as a byte. This means that PHP only supports a 256-character set, and hence does not offer native Unicode support. See details of the string type.

The tutorial is broken up into different sections for easier consumption:

• Single quoted
• Double quoted
• Heredoc
• Nowdoc
• Variable parsing
• String access and modification by character
• Useful functions and operators
• Converting to string
• String conversion to numbers
• Details of the String Type

New from the rooJSolutions blog there's a post pointing out an issue that PHP 5.3.7 has broken the is_a functionality in a lot of cases. The post talks some about what's broken and how you can work around it if you're effected.

The key issue was that 5.3.7 accidentally broke is_a() for a reasonably large number of users. Unfortunately the fixup release 5.3.8 did not address this 'mistake', and after a rather fruitless exchange I gave up trying to persuade the group (most people on mailing list), that reverting the change was rather critical (at least pierre supported reverting it in the 5.3.* series).

This new issue was causing some strange errors to pop up in his code because of a parameter type change in the is_a call, updating the first parameter to be an object instead of a class name. The is_a() call sends its requests to __autoload in some cases and the string->object mismatch of those parameters causes errors to be thrown. His workaround is, in your checking, just be sure to call an is_object first before passing things off to be is_a() checked and autoloaded.

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.

In a new post today Rob Allen shows a method you can drop into your Zend Framework application to allow Zend_Config_Ini to take in a string instead of being restricted to loading a file.

With PHP 5.3 however there is is a new function called parse_ini_string() which will allow us to load arbitrary ini string into Zend_Config objects. This can't go into Zend Framework 1 though due to our PHP 5.2.4 minimum version requirement. As I needed this for a project, I extended Zend_Config_Ini to support this feature, which means simply overloading a single method.

He includes the code for the method - the App_Config_Ini class that includes a _parseIniFile method that checks to see if the last four characters of the input value are ".ini". If so, it loads like normal. If not, it assumes it's a configuration string and parses it with the new parse_ini_string method.

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.