On the PHP::Impact blog Federico Cargnelutti has posted a comparison of using static factory methods to create an instance of a class versus making an object, calling the constructor.

Normally, creating an instance of a class is done by calling new, which calls the constructor. Static factory provides a static method that returns an instance of the class. So, you are using static factory instead of the constructor. Providing a static factory method instead of a public constructor has both advantages and disadvantages.

He includes some of the advantages of the factory method and others for the normal call to create an object. He also mentions some comments made by Dagfinn Reiersol in a blog post about public constructors.

Greg Beaver, noting some issues that Derick Rethans had pointed out about namespace support for upcoming PHP versions, has posted about a patch he submitted to solve the problem simply.

The issue Derick pointed out:

In PHP 5.3 this would alias the class Interval in the namespace PEAR::Date to the class Interval. For now, this code would work just fine. However, if PHP would introduce a class "Interval" at some point in the future (and PHP can do this as it owns the global namespace) then the above code would suddenly stop working.

Greg's patch makes it possible to "override" the internal class if need be, making it so that code currently working wouldn't break. All it takes is to "use" is like you normally would and and the magic happens behind the scenes.

According to the PHP in Action blog, public constructors can be hazardous to your (application's) health and should be replaced.

Everybody who writes object-oriented code knows about constructors. You need them so the program knows how to instantiate objects, right? And you especially need them when a lot of things have to be done while instantiating an object. [...] So why would I be skeptical of public constructors?

The solution, as he sees it, is to make a "constructor" that's actually called statically with parameters that returns an instance of the class it's in as well as performing the action. He argues that this can help make the code much more readable for some types of method calls.

Christian Stocker points out a blog post from Tobias Ebnother showing how to set up a native apache instance on Leopard (OS X) with a 64 bit PHP included.

With massive! help from Marc Ammann I was able to build a PHP Binary that loads with the Leopard shipped Apache.

His method replaces the standard iconv file with a custom built one (based on this source) prior to compiling. Then, in his configure, he sets certain flags, specifically the "arch x86_64" one, to get it to recognize the new setup.

Continuing on from a previous post on multi-threading in PHP, Brian Bosh is back with something a bit more developed that will allow for communication between the threads as well.

Earlier this week, I suggested PHP could be multithreaded. The sample I provided was very simple and at least one reader quickly wondered how to communicate with threads. If you haven't already, take a look at part 1 to get some basic information about threads in PHP.

It took a bit longer to get that part working that simple threads, but as of now, I have a functional prototype of an HVAC thread.

The post is broken up into five different files to make things work:

• an overall class for the main functionality (their example of running the heater or AC)
• a class to create and set up a thread
• a "thready utility" class to handle the response from a thread
• a thread library to handle creation/interaction/etc
• the example file of the system in use

Matthew Weir O'Phinney wonders about singletons. He wonders how he can make them more flexible than they even are by making entire custom singletons accessible later, after they've been created.

This morning, I was wondering about how to extend a singleton class such that you could retrieve the new class when retrieving the singleton later. In particular, Zend_Controller_Front is a singleton, but what if I want to extend it later? A number of plugins in the Zend Framework, particularly view helpers and routing functionality, make use of the singleton; would I need to alter all of these later so I could make use of the new subclass?

He gives two code examples to illustrate his point - one that uses the current Zend_Controller_Front implementation to extend an instance and the other with a slightly modified version to do the same. The change is in the declaration of the $_instance value. By making it protected, the differently extended instance will be created. With the normal setting (private) you'll only ever get back the same default Zend_Controller_Front instance.

Check out the comments for some other suggestions as well.