Static helpers seem to be a great idea at first glance, as they're reusable components that don't require any kind of expensive instantiation for doing common tasks [...]. But the sad and unavoidable truth is in many cases they're simply wrappers for procedural code, which has been elegantly hidden behind a "class" construct. So what's wrong with this? Well, even in the most harmless situations, when you use a static helper that produces a deterministic output, you're actually throwing away the advantages that OOP provides.

To illustrate, they create a basic validation class that can check for things like valid emails, float values, integers and URLs using PHP's filter_var function. They point out that the class is difficult to extend and that it is doing too many things to be correctly considered a "piece" of functionality. To correct the problem, they opt for a different approach - an abstract class acting as an interface to structure custom validators against. This provides set/get methods for things like the error message and value to evaluate. The implementation of the validators on top of this class is coming in the next part of the series.

One of the decisions that has to be made each time an application is written for distribution is how best to set up the configuration files. There are a number of different approaches taken to this: some opt to use the define() function and define constants, while others use large arrays.

He points out a few "overlooked options" that some developers might no consider when working with configuration files like class constants and ini files (which PHP can parse natively). A few code snippets are included to show examples of them in use.

I was running into a few errors, and getResultCode() was obligingly returning the value of the constant, rather than the constant itself. I had to look up what that value meant. For some reason I couldn't reflect the extension to get the constants and values thereof, so with some lame scraping you get the following.

He's included the list in both a normal text format and as a PHP array that can be cut and pasted directly into a library.

Over the last few days I have been digging deep into the concepts of REST. I have been reading through my copy of RESTful Web Services. Out of curiosity I searched Google for a "php REST library" and it turned up the Official MySpace PHP REST Library.

He points out one interesting thing about it, though - it's like they started using an object-oriented design but build after making the classes with properties. No methods.

Even if they were to choose to go the PHP 5 way I would highly suggest that they do not use classes as containers for constants, there is no need to do this. It is not using proper OOP methodologies. Why create an object that just holds 2 - 4 constant variables, these would be better suited for define() calls in my opinion.

Magic methods, which are class methods with specific names, are used to perform various specialized tasks. They are grouped into two: overloading methods and non-overloading methods. [...] Magic functions, which are similar to magic methods, but are just plain functions outside any class. [...] Magic constants, which are similar to constants in notation, but act more like "dynamic" constants. We'll also look at some practical examples of using some of these, and lastly we'll check out what new features PHP 5.3 is going to add.

He looks at the various functions/methods and constants (like __clone, __toString), some of the overloading methods like __call, and magic constants like __FILE__ and __CLASS__. He wraps it up by briefly discussing what PHP 5.3 adds in - a few new magic methods and constants (but no functions).

That's how this new post on the PHP in Action blog starts this morning. The one thing that he wants is enumeration support in PHP. He shows how it can currently come close with a "roles" system:

Useful examples I've encountered in web programming are states or stages in a process and user roles. Another kind of example is one I used in PHP In Action: an authorization system with three fixed roles or categories of user: regular, webmaster and administrator.

He sets up an example class that sets constants for the different access levels rather than just relying on strings to handle it (which, as he points out, could very easily be misspelled and not throw any kind of error) .

There are thousands of services available on web who are presenting interesting as well as education information which you can really integrate in your web page or make a nice widget and let others use them seamlessly with their content delivery platforms. In this article I am going to show you how you can make a nice Today-in-History widget with the help of the data provided in Scopesys.

He wisely recommends that you check one thing first about the content you're grabbing - the copyright it carries with it. This could get you into big trouble down the line depending on whose content it is. The actual script is pretty simple - he defines some constants as markers for where things start and stop in the HTML and then uses strpos to get the locations for his substr call to grab the segments.

My issue is not with the language itself (this time!) but how this sort of documentation is handled. Updating public documentation well ahead of a release creates confusion.

He's referring to the documentation for the class constants not quite matching up with the current functionality (resulting in a T_PAAMAYIM_NEKUDOTAYIM). He wants consistency in the documentation and maybe references to what it requires to use a certain bit of code.

In PHP 5.3 there will be another magic constant __DIR__. [...] To allow this, the internal function php_dirname() has been moved in the Zend Engine and is now called zend_dirname(). Nevertheless an alias still exists.

__DIR__ will join the other constants (like __LINE__ and __FUNCTION__) to help give the currently running script a little introspection for things like its filename, what class it's currently in and now, what directory the file currently lives in.

Yes, you know what code you write and you also know how it works. You can find your way around it. But what if you haven't touched a piece of code for months or even years. Or what if someone else needs to work with your code. Prevent a hell: use clearly readable variable names and constants.

He points out an example of what not to do - a specific line from the FUDForum code with multiple variables named with a single letter of the alphabet in a complex if() evaluation. He suggests even using "namespacing" of sorts (PHP6 here we come!) to help compartmentalize your variables to make things even easier.