So a user signs up and I want to store a status that reflects their account, or at least an identifier representing that status. Their account could be active, disabled (temporarily), pending approval or maybe deleted. Should I use an enum? I've heard they're evil. Maybe having a reference table with statuses would be better? But now I have to manage a separate table just for that one snippet of data, is that overkill? Could I maybe use that status table for other entities? Or, could I instead just use an integer and reference it on the code level? What is the right solution?

He presents three of the most common situations he's seen for people using enums in the application:

• "I used enums all over the place" (maintenance between code and DB values)
• "use a reference table"
• "I could use a class constant to represent the enum" (enforced in the app)

Of the three, he suggests the third as the option with the most advantages. Not only does it make it simpler to get the allowed values for the field, but you're also more flexible in the kinds of validation you can do on the values.

This function returns an array with the elements allowed in a ENUM or SET mysql field. This can be usefull if you're making some automation and need to retrieve those values without writing them in your code.

The function uses the database's metadata to get the column information for a table and filter out the "enum" information from that. The column information includes the set of values possible and a few simple string handling functions make it easy to grab them. They could also be replaced by a regular expression or two to grab the same information more concisely.

The field users.level is an enum type and can have the values 'guest', 'user', 'admin', 'superadmin' and 'root'. The problem is that it could be possible that new levels were added in the future. [...] So what I came up with is a very simple behavior that can extract the options for any ENUM field. It uses simple caching in order for the query to not be run all the time, so make sure to clear your cache as you update your enum field options in the db.

His code snippet creates an EnumerableBehavior for the model and grabs the column names from the given table to check the access level for each and write them out to a cache.

If you want to implement Enum behaviour with a simple string or int value you end up with having to validate the values at several different locations in the code rather than being able to strictly enforce the Enum structure by using typehints.

In an effort to try to help the situation he and a colleague came up with an abstract class MyEnum that uses the __toString method to do value checking. Code examples are included for the class and how to use it.

I stumbled across a blog post on how to implement Enums in PHP via userland code written by Jonathan Hohle. I liked the concept he had, but the implementation was a bit unappealing because it used eval() among other more minor issues. You shouldn't need to generate Enums at runtime, so I took that as a challenge to find a way to do it at compile time, thus making the code much more efficient.

His enums would support type hinting and would, ideally, be iterable. He gives the code he's worked up - a base class, another than extends it to make a basic enum structure and some handy changes to support comparisons. A few more changes (and a few other extended classes later) he has some pretty well functioning enums that can even bee iterated through.

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