In a new post to his site Stoimen Popov makes the recommendation to not call the destructor explicitly in your code and provides some alternatives.

PHP 5 introduces a destructor concept similar to that of other object-oriented languages, such as C++” says the documentation for destructors. [...] Well, as you can not call the constructor explicitly [...] so we should not call the destructor explicitly. The problem is that I’ve seen this many times, but it’s a pity that this won’t destroy the object and it is still a valid PHP code.

He talks about __destruct and it's role in PHP's set of "magic methods" and what they exist to do. He then gets into a few examples of what code could look like that uses a destructor and the difference between normal handling calling the destructor explicitly. The main differences is that calling it explicitly does not destroy the object, it's basically like calling any other method. He does include an interesting method for destroying the object - setting it to null - and notes that the destructor fires then too. He also points out a few interesting things about cloning objects and how object references work when setting nulls as in the previous example.

Ben Ramsey has shared an interesting issue he's come across when installing packages via Composer where it installed a different version than expected when he ran an install. The problem turned out to be from an unexpected place.

For applications I control that are not distributed to the public, I like to hard-lock my Composer dependencies to a specific version. [...] Sometimes a library has updates that haven’t yet been released, and I need to use these right away. Composer allows me to specify the specific commit I want to use for a library. In this way, I can hard-lock a dependency to a specific state, even when there is not yet a release for the changes I need. This has worked well until today, when I tried to do a fresh composer install. After installing, one library contained files and methods that I did not expect. It turns out Composer was grabbing the HEAD of dev-master instead of the specific commit I referenced.

After some investigation into his "composer.lock" file's contents, he found the issue: a problem with the way that BitBucket handles the distribution zip files Composer requests. In his example, the zip file was of the HEAD on the repository, not of the specific commit (GitHub doesn't have this problem). His solution was using the (slower) "--prefer-source" option to grab the correct commit contents...not an ideal solution but it does what he needs.