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.

Updating from a previous post, Jonathan Snook has updates some of his comments about a simple way to make static pages in your CakePHP framework application:

So it seems that the old code I had didn't work in debug mode, although on the current CakePHP 1.2 RC2, I'm not even sure it works at all. However, I decided to take some time to revisit the code. Last time, I simply hacked up the missingAction and missingController calls and it felt kludgy. It looked kludgy.

Instead of abusing the error handler like before he decides to opt for this missingAction/missingController combo to handle the fall through. It doesn't seem to be working 100% correctly, though and he's put in a ticket to see if its a bug or by design.

On his blog today, Stefan Mischook shares his reasoning for making all of your pages PHP pages, regardless of static content or dynamic.

By making all your web pages PHP pages from the start, you are basically leaving open the possibility of using PHP in your web pages at any time.

By his reasoning, it provides an "out" for you later on should you decide that a page needs to have some dynamic content thrown in there somewhere (without having to change the filename - bad for SEO, supposedly).

Micheal Kimsal has pointed out another "bugbear" he's found in his work with PHP - this time it's with the use of class constants.

My issue is not with the language itself (this time!) but how this sort of documentation is handled. Updating public documentation well ahead of a release creates confusion.

He's referring to the documentation for the class constants not quite matching up with the current functionality (resulting in a T_PAAMAYIM_NEKUDOTAYIM). He wants consistency in the documentation and maybe references to what it requires to use a certain bit of code.

Antony Dovgal points out that Derick Rethans has added the snapshots for PHP 5.3 to the snaps.php.net website.

Short list of what you can find there: Namespaces, __callstatic() magic method, accessing static members through $foo::myFunc(), fully rewritten ini-parser with .htaccess-like user defined ini files for CGI/FastCGI, improved OpenSSL extension, PCRE 7.4, and other fixes and improvements that will never get into 5_2 branch.

He recommends teching throughly before the major release to find all of the bug before the general public does. Builds for both source and Windows systems have been posted.

In a recent post to his blog, Brian Moon talks about the experience he's had with using PHP on Apache 2 with a threaded MPM at Dealnews.com.

Well, first, what is an MPM? It stands for Multi-Processing Module. [...] The most commonly used threaded MPM is the Worker MPM. In this MPM, you have several processes that run multiple threads within it. This is the one I will be talking about.

He goes on to describe the "huge memory savings" that using the module got them - using the worker process to increase the child capacity of the Apache instance. He recommends keeping it simple when compiling a server to work with the worker functionality and mentions how it can also help with serving static pages right along side the dynamic ones (without a second server!).

Check out the post for a few more tips.

On the SitePoint PHP Blog today Troels Knak-Nielsen asks th3e question "what's so bad about the singleton?" For all of its advantages, is there a darker side of the design pattern when it pertains to global variables.

As I have often taken this stance myself, I found it reasonable that I should be able to argue for it, so I'll try to give an explanation. This is also in part a follow-up on my post from last week, in which I present a way to avoid global symbols, without spending much time on why.

He talks about what they are and how they're commonly used - sometimes with some unpleasant side effects because of their use of globals.

Sean Coates has posted a new article today about one of the features that will be included in the next major release of PHP (5.3) - late static bindings.

Late Static Binding (LSB) is a topic that's been brought up numerous times in the past three years in various PHP development discussion circles (and we're finally getting it in PHP 5.3)â€"but what does it really do, and why should you care? Here's a simple practical example of how it can greatly simplify your code's design.

He shows its usefulness in an example of how it works, letting classes/objects access static methods, constants and properties of inherited classes (besides their own). His example (using beer, of course) shows how an extended class (Ale) can reference the constant (NAME) in the parent class (Beer). Thanks to a new keyword in PHP 5.3 - "static::" - helps define the difference even clearer.

Check out the rest of the article for a more practical usage too.

Jonathan Snook has posted about a method he's using to make the creation/use of static pages in a CakePHP application (or website) simpler.

Traditionally in a CakePHP application, to do static pages you have two options: use the built-in Pages controller or set up an empty action in a controller.

Feeling that neither of these two options met how he wanted things to work, Jonathan (and Nate Abele) developed a class that extends the error handler in the CakePHP framework to handle "missing" actions and controllers. This means that, if an unknown controller/action combo is called, this script will check in its correct location (in the structure of the site) and try to find it to render it.

Taking full advantage of the upcoming features in the PHP 5.3.x series (and in PHP6 for that matter), Joshua Thompson has come up with a way to accomplish some prototype-based programming in a PHP application:

With the implementation of the get_called_class() function in PHP, prototype based programming in PHP is possible. The new function is in both PHP5.3 and PHP6 snapshots. So, I went back to the drawing board and came up with a fully capable class. The $this keyword is usable, as well as being able to use the self, parent, and static (new with the late static binding patch) keywords.

Prototype-based programming is (basically) a method where classes aren't prebuilt. Instead they are created on the fly based on other objects and interfaces. Joshua's post is a huge code dump of a prototype class and an example of it in use, dynamically creating two methods and making the three objects available.