I want Enums in PHP

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) .

Hasin Hayder has written up a quick tutorial for his blog that shows how to create your own "Today in History" page with details from Scopesys pulled with a little web scraping.

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.

Micheal Kimsal has pointed out another "bugbear" he's found in his work with PHP - this time it's with the use of class constants.

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 this new blog post today, Lars Strojny talks about a new magic constant that will be joining its brothers in the upcoming PHP 5.3 release - __DIR__.

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.

Stefan Koopmanschap has a good reminder for developers out there in a new post to his blog - make your code much easier to understand via readable variable names and constants.

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.

Ivo Jansch discovered something interesting by way of an applicant's resume - a hidden "trick" that PHP pulls on the user when they try to use a Java-like syntax with System.

So yesterday I was reviewing a code sample that a job applicant had written during a test and I encountered the following line of code: It's not hard to guess what his background was :), but I was initially stunned that this actually works in php.

After a little investigating (and ruling out the Java Bridge), Ivo found that the line was being interpreted literally and was just being handled as a string instead of a constant. He gives two other examples to help with clarification.

Pierre-Alain Joye has three different posts to his blog about the releases of new versions (or new software) he (and others) have posted recently - a new release candidate for GD, the new Hidef extension in PECL, and a bug release for the zip extension.

• The first post concerns the Zip extension release and which of the provided libraries you should use with your PHP installation (he recommends the latest PECL version over the included version). There's also a link to the new release - 1.8.6
• The second post is an announcement about the publishing of the Hidef extension into the PECL library (by Gopal Vijayaraghavan). It can be used to do a "one time declare" of constants in your application, working with a configuration file to only load them the first time the browser hits the site/application.
• Finally, in the newest of the posts, Pierre points out a brand new release candidate for GD 2.0.35 to two possible correct race conditions. You can download this new release here: tar.gz file, tar.bz2 file

WebReference.com has posted part three of their "Building Blocks" series - a look at data types, literals, variables, and constants.

In part three, they focus more on the last type of "block" in their list - the constant:

Some real-world constants, such as pi, the speed of light, the number of inches in a foot, and the value of midnight, are values that don't change. PHP not only provides its own predefined constants but lets you create your own. Using constants makes it easy to write and maintain your programs.

There's talk of the define() and constant() functions and a mention of some of the predefined and "magic constants" as well.

Constants can be handy when used correctly. Unfortunately, there's some small issues you might want to watch out for. Ben Ramsey discovered one while working with another's code - an undefined constant acting like a string.

From the I-noticed-this-one-day-while-looking-at-a-co-worker's-code department comes a tale about the use of undefined constants in PHP'"and relying on this twisted "feature" to make an application function properly.

He relays a little story about the errant code and noticed the constant that wasn't defined and how PHP was treating it like a string. After searching the manual, though, he finds a reference related to the situation showing that it will only throw an E_NOTICE when this happens.

Ben's suggestion is for a bit more than that - at the very least an E_WARNING. Having it down at E_NOTICE won't be seen by most with the default php.ini, and he gives an example as to why it's a bad thing (passing this string/constant into a function and how it handles it).

Chalk this up as par for the course in the world of PHP, but it doesn't behave as documented. I noticed today that @ work someone is creating database connections, then define()ing the result into a constant. I presumed this was failing silently and because we were generally connecting to only one database (or so I thought initially) that it was simply using the last open connection and still working.

This does *not* throw an error, but does in fact work. Even going back to PHP 4.3.2 (earliest I've checked). This flies in the face of my understanding of constants for years - well, since 1998 (perhaps earlier) or so.

the issue - that a resource can be assigned to a constant - seems to contradict what's listed in the manual, and he asks later if there are others out there that have seen this same issue...