DevShed has posted the second to last part of their tutorial series looking at the magic functions in PHP. This time they focus on the destruct function, a method that is fired off when an object is being removed from memory.

There are a few [other methods] that can be really useful for performing relatively complex tasks with a minimal amount of code. That's exactly the case with the "__destruct()" method, which will be called automatically by the PHP engine before destroying an instance of a particular class at the end of a script.

They update their example class with a new __destruct method that takes the user information inserted previously, serializes it and drops it into the current session.

While working with some code of his, Travis Swicegood noticed something odd when he tried to work with Exceptions in a __destruct call:

You must be doing something right when you can send PHP into a tail spin. That or the code you're trying to do is just evil. Turns out __destruct() and __call() don't play well together in 5.2.4 if, and only if, you create an instance of an object without assigning it.

The official (and verified) bug over on the bugs.php.net site gets into more detail on it including a code block that illustrates the point as simply as possible.

In the example I blogged about, __destruct() actually wants to catch any exceptions so it can create meaningful output based on the Exceptions that were generated. In that case, __destruct() would have returned peacefully. [...] At any rate, my take on that would be that would still be that if __destruct() is finished and an exception is still present, then there's an error. Otherwise, how would you handle things such as PDOExceptions thrown during DB clean-up?

While working with some code of his, Travis Swicegood noticed something odd when he tried to work with Exceptions in a __destruct call:

You must be doing something right when you can send PHP into a tail spin. That or the code you're trying to do is just evil. Turns out __destruct() and __call() don't play well together in 5.2.4 if, and only if, you create an instance of an object without assigning it.

The official (and verified) bug over on the bugs.php.net site gets into more detail on it including a code block that illustrates the point as simply as possible.

In the example I blogged about, __destruct() actually wants to catch any exceptions so it can create meaningful output based on the Exceptions that were generated. In that case, __destruct() would have returned peacefully. [...] At any rate, my take on that would be that would still be that if __destruct() is finished and an exception is still present, then there's an error. Otherwise, how would you handle things such as PDOExceptions thrown during DB clean-up?

On PHP-Coding-Practices.com, Tim Koschuetzki has posted a new tutorial that just might save your life - well, at least the life of your CakePHP application - using table migrations.

Migrations are a wonderful technique to keep your database in sync with your code. When working on a project as a team, migrations can save your life. Please join me and get a quick introduction to migrations in CakePHP and become a happier coder.

He starts by explaining what migrations are (yml files that contain database construction/destruction information), how to execute them in your application, and how to construct your own.

On PHP-Coding-Practices.com, Tim Koschuetzki has posted a new tutorial that just might save your life - well, at least the life of your CakePHP application - using table migrations.

Migrations are a wonderful technique to keep your database in sync with your code. When working on a project as a team, migrations can save your life. Please join me and get a quick introduction to migrations in CakePHP and become a happier coder.

He starts by explaining what migrations are (yml files that contain database construction/destruction information), how to execute them in your application, and how to construct your own.