In this new post to his blog Stoimen Popov talks about calling the "destructor" method of an object and why doing it directly could lead to some issues - like not actually destroying the object before the script ends.

At the end of the script the interpreter frees the memory. Actually every object has a built-in destructor, just like it has built-in constructor. So even we don't define it explicitly, the object has its destructor. Usually this destructor is executed at the end of the script, or whenever the object isn't needed anymore. This can happen, for instance, at the end of a function body. Now if we call the destructor explicitly, which as I said I've seen many times, here's what happen. As you can see calling the destructor explicitly doesn't destroy the object. So the question is...how to destroy an object before the script stops?

He points out that one way to "destroy" an object is to null it out and remove the structure from memory. This is tricky, though, because a clone of the object will still exist in memory, just not the original.

Artur Ejsmont has a new post with a passionate call to arms for anyone who thinks that just because their URL has "https" in it, it's secure. He presents his suggestion on how to properly secure SSL API calls for your PHP application.

Lets make something clear from the very start: JUST BECAUSE THERE IS https:// IN THE URL OF THE REMOTE SERVICE IT DOES NOT MEAN THE CONNECTION IS SECURE! I am sorry for the tone of this post but i am enraged by how popular this issue is online. If you ask why i suggest a little experiment [involving changing your hosts file and using a self-signed certificate].

The issue he spotlights is all too common - a server serves up SSL pages but doesn't actually verify the certificate in the process. He gives a bad example of how some scripts handle this issue using the CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST to turn off this verification - a very bad idea. To protect yourself from any kind of man-in-the-middle or DNS hijack issues, you should leave these on.

Stoyan Stefanov has a new post to his blog looking at bringing something to PHP that Javascript developers have always had - object literals. These literals allow you to assign object properties at definition time instead of the usual PHP method of adding them either in the class definition or after the object exists.

Stoyan starts with an example of the object literals on Javascript and shows how it's (sort of) possible to replicate that wit type casting an array to an object in PHP. The tricky part comes in when you try to recreate the method handling JS gives in objects. Closures in PHP 5.3 comes close, but there's a few things he points out that just won't work the same way.

You can simulate some of this with __call method handling in a base "JSObject" class. For more details on his work bringing Javascript over to the world of PHP, check out his presentation from this year's ConFoo conference.

On the Stubbles blog today Frank Kleine looks at a cool trick that the features of PHP 5.3 now make possible - extending objects at runtime by adding in new methods and functionality.

With the advent of PHP 5.3 adding new methods to an instance of a class at runtime becomes possible with PHP as well, using anonymous functions and a little bit of __call() magic.

He illustrates with a bit of code - defining the base class and using a __call method to catch any undefined method calls. Using this in conjunction with closures makes it possible to call the method internally, avoiding the usual error that could result from setting it like you would a class property.

Continuing their look at the "magic functions" that are included in PHP5, DevShed has posted this new tutorial looking at the "__call" method to intercept calls to methods in a class that don't exist.

If you're a PHP developer who wishes to learn how to implement and use the set of magic functions that come included with PHP 5, you've come to the right place. [...] As the title of this article suggests, in the new few lines I'm going to take a deeper look at the"__call()" function, so that you can quickly become familiar with it.

They include code examples of the __call method in use - catching a call to a "fetch" method.

This new tutorial from DevShed takes a look at the XDebug debugging tool for PHP and how the xdebug_call_function method allows for even more flexibility in your testing experience.

The Xdebug extension comes equipped with many other functions, however, that allow you to debug PHP applications more deeply. Therefore, in this second article of the series, I'll be discussing how to use another useful function included with the extension, called "xdebug_call_function()," which as its name suggests, can be utilized for keeping track of the functions called by a PHP script.

They start with a look back at two of the other xdebug functions - xdebug_call_file and xdebug_call_line - before showing how to use this new function (xdebug_call_function) to get the function that called your custom handler.

Martynas Jusevicius has a new post looking at method overloading in PHP5 - a workaround to make it possible at least.

Method overloading (a feature of object-oriented programing which allows having several class methods with the same name but different signatures) is not implemented in PHP, which is a drawback compared to Java. However, PHP 5 provides a way to imitate overloading by catching calls to "inaccessible methods" with magic method __call.

In his example he uses __call to route the request to the correct version of the constructor (__construct0 or __construct1) based on the number of arguments passed in

On the Ibuildings blog today Lorenzo Alberton takes a look at the Zend Framework, specifically as to how it can mimic regular HTTP calls with the built-in components.

One of the unit testing best practices suggests to break dependencies, so you can test each component separately. The first problem that arises when you want to test controllers might be having a tighter control over the HTTP Request and Response objects.

This problem is overcome with the Zend_Test_PHPUnit_ControllerTestCase. The second problem it with calls to external resources (like models/databases or web services). This is the prime focus of the post and seceral blocks of code are included to make a class to emulate the HTTP responses you might get back from the service.

In a recent post to his blog Dhiraj Patra looks at the caching functionality that PEAR has to offer via the PEAR Cache package.

Caching is currently a hot topic in the PHP world. Because PHP produces dynamic web pages, scripts must be run and results must be calculated each time a web page is requested, regardless if the results are the same each time. In addition, PHP compiles the script every time it is requested. [...] PEAR's Cache package offers a framework for the caching of dynamic content, database queries, and PHP function calls.

He talks a bit about what kind of methods are included with the package and shows examples of how it works for function call caching, caching the output from the script execution and how to implement your own custom caching extension of the main code to make it even more flexible.

Stefan Mischook has a (very) basic introduction video posted showing how to call functions/methods from another class outside the one you're currently using.

Recently I was asked by someone how they could call a function found in one class, in another. This may seem like basic stuff to those of us who know...but please keep in mind, at one time, none of us knew anything!

You can check out the video here. Be sure to check out more of the great videos he's created too on topics ranging from MVC frameworks to a beginner's guide to PHP.