Stubblog

About a year ago I wrote about How to get a Singleton right. While nothing has changed my opinion about the Singleton Design Pattern - contrary, I'm even more convinced that it is bad, bad and bad - I still have homework to do. In the comments to this article I was asked about my opinion on the Registry Design Pattern, and I promised it would be worth an own blog entry. Well, I did not anticipate it would take more than a year to write it, but you know, work, and no time, and yada yada yada... so here it is.

When thinking about a Registry one has to consider two points: overall architecture of the application, and implementation of the Registry itself. It's not that much what you can say about the implementation of a Registry. For PHP, it should just follow one rule to make it testable and to ease testing of classes using the registry: do not make it a Singleton. (You might have guessed that already.) PHP offers the possibility to implement the Registry as a pure static class, where data within the Registry can be stored within a static class variable, and setters as well as getters can also be static methods. There is no value in making it a Singleton, it just more stuff to type where the result is the same: global state. So if you implement it as pure static, the Registry in itself is neither bad or good.

Speaking of global state, it should be common sense by now that global state is a bad idea, at least if this global does not mean the root of the application itself, which leads us to the overall architecture of the application. How is this related to the Registry Design Pattern? The Registry is intended to allow access to configuration data, objects etc. which you don't want to pass around in your application but require them in different parts (or layers) of your applications. If you have such a need from my point of view this means the application is not fully based on the Dependency Injection principle, it does not separate object creation and business logic as much as it should. If the application is completely based on Dependency Injection, there is no need for a Registry any more.

Did I just say that there is no need for a Registry any more? Well, two exceptions. First, unfortunately in PHP there might be cases where you can not influence the creation of an object instance, and if you want to pass data or other objects to such an instance, you have to take cumbersome actions to pass those. Creation of user land stream wrapper instances is such an example, as those instances are created by PHP itself and there is no possibility to intercept this. Here a Registry might be of help, but it stays what it is: a workaround for a flaw in PHP.

The other exception is the case of using a Dependency Injection framework. You do not need a Registry here - your DI framework already has something like this. It just not called Registry, but it is it's mechanism where you bind data or objects for example in the case of Stubbles or Google Guice, and in Symfony it is called Service Container. (Please note that this is just a quick thought I had in the last days, I might be wrong on this.)

To conclude, the Registry itself is neither useful or harmful. The more important question is how strong you apply the Dependency Injection principle in your application.

Some minutes ago we released Stubbles 1.0.2. This is a bugfix release, containing the following fixes:

• added support in ingrid for selected attribute


• fixed bugs in ingrid with field and id names


• deferred loading of request value error message data until first creation of such a request value error message


• fixed defect #233: stubMailValidator doesn't support uppercase letters

You can get the release from our downloads page.

Some minutes ago we released Stubbles 1.0.1. This is a bugfix release, containing the following fixes:

• fixed security issue: route name not checked correctly


• prevented loading of already loaded XJConf classes and interfaces


• optimized annotation cache: write cache file only if annotation data changes


• fixed ticket #226: @ProvidedBy does not support .class notation

We encourage all users to upgrade due to a security issue with 1.0.0 with route names where the validation of the selected route name was not done properly. You can get the release from our downloads page.

This weekend we released Stubbles 1.0.0 as the first non-alpha/non-beta version, recommended for production usage. We decided to drop all view engines except the XML/XSL one as we recommend only using this. The Memphis view engine using patTemplate was just a heavy steel ball on our feets, and our decision to drop it manifested in the way that we were able to improve Dependency Injection support all over the way for the XML/XSL view engine.

Further improvements compared to the last release focused on the command line support. Now you can write your script as implementation of the net::stubbles::console::stubConsoleCommand, using Dependency Injection in all places, and run the command with our new stubcli script which is capable of running all net::stubbles::console::stubConsoleCommand implementations.

The filter API saw a major rework making it simpler then ever to apply filters to input values. We will improve the validator API in the same way with the 1.1.0 release.

Of course several bug fixes found their way into the release. See changelog for a complete list of changes. You can get the release from our download pages.

Unfortunately the documention is not complete. If you have questions just open tickets, we will address documentation issues then.

What's next? We have planned bugfix releases for 1.0.0 if necessary. Additionally we already planned the 1.1.0 release. See list of tickets for milestone 1.1.0 on what we have planned.

This weekend I attended the PHP Unconference in the lovely city of Hamburg (if you don't count the wheather in). It was a really great event with a superb organisation, from my point of view even better then the some "professional" conferences. So, first a big thank you to the hosts from the PHP Usergroup Hamburg, you did a wonderful job.

Speaking about professional conferences, it's interesting to see that I'm not the only one with a very sceptical look on the International PHP Conference. Other attendees I spoke with had similar thoughts: always the same speakers with nearly the same topics, degrading the purpose of IPC to networking only. It would be more interesting with more fresh blood and a broader range of topics. Of course this would mean more risk for the host, but I believe in the long run the current development will ruin the IPC. Or can I just not imagine that there are so much companies out there paying several hundred Euros just for networking?

From the sessions I attended the Performance pessimization talk was really fun and insightful. Starting with an optimal (hardware) architecture Kris Köhntopp, Johann Hartmann, Stefan Priebsch and Lars Jankofsky made changes to this architecture to decrease its performance one after another. Both the audience and the speakers had very much fun in adding one "improvement" after another.

For the PHP in the Enterprise session I have rather mixed feelings. While Kris Köhntopp made some really good remarks on maturity of business models and their surrounding processes I think the whole session suffered from an undefined target. "Talking about Enterprise PHP" is not sufficient as session target. It was like a "Let's have a meeting on topic X, but we don't define an agenda for it." Well, from that point it was really enterprisy.

Together with Thorsten Rinne I did a presentation on Things to consider for testable code - I feel a bit sorry for Thorsten as his main purpose was to stress the important points of my presentation rather then talking about refactoring bad code to better code, the topic originally voted for.

To my surprise the audience seemed to appreciate it. I was very unsure if it would work out in the way I intended it. Probably I should add more examples for the Dependency Injection part as it was requested to see some real-life code, however I'm not sure how much it helped to better understand how it works. In every case I will add one or another point against Dependency Injection, as it seems that there are only benefits but no drawbacks. If you attended the session and would like to give feedback about what can be improved please drop a comment.

On sunday Oliver Müller (Btw, thanks to Oliver for taking us on a tourist tour around the Reeperbahn on saturday night. ) gave an interesting overview of current state-of-the-art technologies for implementing Single Sign-on systems. It raised new questions for a project I will do in the upcoming months.

Another interesting session was from Stefan Priebsch about the Model-View-Controler (MVC) design pattern. While I felt uncomfortable with the label "MVC" on Stubbles for quite some time now the talk finally convinced me to drop this label. MVC in the web is fundamentally different from MVC in desktop gui applications, where it was originally invented for, and there seems to be no common understanding of what MVC in web applications should really look like. That's not surprising as there are different solutions possible, and it strongly depends on the type and size of the application you create. Heck, there are even frameworks out there with a "Model" class you should inherit all your models from, which is independend of the application totally pointless and makes me cry.

Because the Deployment talk took not place due to a missing speaker I switched to a MySQL High Availability talk. I'm really glad we have database admins in our company which take care of this, but it was interesting to see what the important points are and how such an architecture is build.

The last talk was about experiences on pre-commit-hooks. It was suggested to deny commits if they do not fulfill the coding guidelines. For projects with release cycles of at least several days it seems to be really useful, but if you do several releases per day it has a high chance of getting in the way in the moment you want to deploy a bugfix for a bug you deployed earlier the day. (Please do not comment that one should not do this - it boils down to a business decision if you do it or not, wheighing less quality against time to market.) Doing a php lint check and enforcing a certain style of commit messages however seem to be useful in such projects as well.

Finally: thanks to everyone who attended. It was a great event with really interesting topics, chats and a fantastic atmosphere.

While the title of this blog entry might sound rather scary to straight OO evangelists it might attract other developers - e.g. those that played around with runkit or had a look into the Ruby world where the language supports adding new methods to a class or just to an instance of a class at runtime (see singleton methods, and this blog article; for those not familiar with Ruby: Fixnum is a class already defined by Ruby core.)

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. First, let's define a new class (boring old foo, bar, baz example for lack of fantasy):
class Foo { public function bar() { echo "This is Foo::bar()\n"; } }

As you surely already know you can add public properties to an instance at any time:
$foo = new Foo(); $foo->baz = 'Hello World.'`;

We can use this to store an anonymous function:
$foo = new Foo(); $foo->baz = function () { echo "This is Foo::\$baz()\n"; };

Unfortunately, we are not able to call this as a method:
$foo->baz();
This will blow up with a fatal error saying "Call to undefined method Foo::baz()". Of course we could do
$func = $foo->baz; $func();
but that is not what we wanted to achieve. Let's add some __call() magic to our Foo class:
class Foo { // method bar() omitted public function __call($method, $args) { if (isset($this->$method) === true) { $func = $this->$method; $func(); } } }
Now we can safely call $foo->baz() with the desired result. However, compared to Ruby you can not redefine existing methods. Therefore,
$foo->bar = function () { echo "This is Foo::\$bar()\n"; }; $foo->bar();
will still call the method Foo::bar() defined earlier and ignore the redefinition due to the nature of how __call() works.

What can you do with it? If you use duck typing this might be useful as it reduces the amount of code required for the Adapter design pattern as you just extend the instance you want to use instead of creating a separate adapter class. The result is the same, both a full fledged adapter class and the closure can only access the public properties and methods of the instance to adapt. Problem is, the class to adapt most likely does not have the required __call() implementation.

Another use case could be a simplified version of the extension methods mechanism where you want to add a method locally without the need to have it available globally in the application.

If you have another good idea of what this can be used for please feel free to comment - just wanted to write my thoughts down.

Some minutes ago I released vfsStream 0.4.0, introducing support for file modes, owners and groups. While I planned to implement this at least since a year it took me three tries to get it implemented, and while implementing this I stumbled about some issues which can not be solved by vfsStream. Major problem is that the PHP functions chmod(), chown() and chgrp() do not work with vfsStream URLs due to limitations imposed by PHP (or possibly by underlying C, not sure). The stream wrapper API has no support to enable setting file modes, owner or group of a userland stream implementation. This means the usage of file mode support is limited and can not be applied to create tests for classes using one of the three functions. However, it is still possible to use file modes for testing correct usage of is_readable(), is_writable() and is_executable(). Another usage scenario is to make sure directories created with mkdir() receive the correct file mode, see the file mode example. I'm sure users will come up with other usage scenarios I did not even thought of.

Beside this new feature the release contains a bugfix for vfsStreamDirectory::addChild() to make sure adding another child of the same name as an existing child replaces this existing child, and a fix to return correct results for stat() calls. Grab the release via it's pear channel pear.php-tools.net and try it out. I suspect the file mode support may contain bugs because I did not have the time to use it in other projects, but after all, it is still in alpha stage.

The current issue of the german PHP magazine features an article about vfsStream. On three pages Mike Wittje (I hope this is the correct Mike, just guessed ) describes how vfsStream can be used to simplify and improve unit tests for classes utilizing the file system and file system functions. Thanks to Mike for writing the article, helping to spread the word about vfsStream.

Over the weekend I'm going to test vfsStream with PHP 5.3 and try to fix any issues which pop up. I already received a patch by mail which is said to fix an issue with is_readable() (not tested yet), so it seems reasonable there will be a new release within the upcoming days.

Last night we released Stubbles 0.16.0 which is mainly a bugfix release but still contains some new stuff. Most remarkable of the new stuff is the native support of Iterator instances to behave as arrays when serialized with the XMLSerializer. Another interesting feature is the possibility to configure the xml generators to be used by the XMLProcessor of the XML/XSL view engine, which allows you to add your own xml generator and have arbitrary data available on the dom tree of every page.

For the command line folks we added the possibility of asynchronous command line execution with the Executor. This way one can issue several commands at once and wait until they are processed while doing other things in the meantime.

Bug fixes focused on the input grid support, making it more usable for everyday usage of forms. For a full list of changes see the changelog.

On another note, this is the last minor release which contains the Memphis and Rasmus view engines. We will discontinue them in trunk and the next minor release will not contain them. However, we will do bugfix releases for the 0.16.x series if necessary and keep the support for 0.16.x until our own applications are migrated to the XML/XSL view engine later this year, meaning that support will be available at least until December 31st 2009.

New month, a new release: 0.15.0. On the last release 0.14.0 I said the next release will most likely be 1.0.0. Turned out, it is not. We don't have a new release date for 1.0.0 yet, as this highly depends on our demand to have its XML/XSL view engine proven in reality, which we do not have a new date for yet.

Beside this, the release brings some new stuff: One could have more then one master.xsl in the XML/XSL view engine now, which means the stylesheet for generating the stylesheet is now highly extensible by custom templates. We improved the net::stubbles::service::soap package by fixing inconsistencies and made it usable in conjunction with our Inversion of Control feature. Speaking about Inversion of Control, we added the @ProvidedBy annotation which can be added to interfaces and classes to declare the default injection provider for those types. This is similar to the @ImplementedBy annotation, but offers more possibilities on what has to be done to construct the requested object.

For a complete list of changes consult our changelog.

Once again, I have to mess around with SOAP, certainly not the last time. For the record: SOAP is for sure one of the first places on the top ten list of the most stupid inventions in software history.

Some minutes ago we released Stubbles 0.14.0. Most likely this is the last release before 1.0.0, which is schedules for end of March or early April, depending on how many bugs we will find until then. But back to the current release, what's new?

One highlight of this release is the introduction of support for JSON-RPC communication with qooxdoo applications. We improved the already existing JSON-RPC support to cope with some qooxdoo specialities, so it should now be possible to create RIA qooxdoo frontends with Stubbles as backend on the server. Compared to the YUI support we currently do not provide the possibility to create JavaScript stubs for the browser side, as this might not be worth the effort due to the ease of requesting data from the server with qooxdoo. At least that's what the programmer said - we will see if it stays that way, it's subject to discussion.

Most of the other changes are improvements of the Inversion of Control feature rework we did with 0.13.0, one is that there is no need any more to explicitly bind the mode, as this is an optional dependency now. Additionally, the net::stubbles::lang::stubMode class is now an interface, allowing users to have their own mode implementations. The implementation delivered with Stubbles can now be found in net::stubbles::lang::stubDefaultMode. Additionally it is now possible to create an application without binding the logger, all dependencies to it were changed to be optional.

As always, for a complete list of changes see the changelog.

Nearly about a year passed since the last release of vfsStream, and some bugs were found by users of vfsStream. This was quite a surprise for me since I did not expect that anybody would use it.
This evening I fixed another bug reported some days ago, and since a patch for another bug was submitted and committed about half a year ago I decided to release version 0.3.2 tonight, so these are the changes:

- added support for trailing slashes on directories in vfsStream urls, patch provided by Gabriel Birke
- fixed bug #4: vfsstream can only be read once, reported by Christoph Bloemer
- enabled multiple iterations at the same time over the same directory

A big thank you to the bug reporters for their help to improve vfsStream. This should give me some motivation to go for 0.4.0 and implement support for file modes, at least being able to store and read them - full file mode support will be a hell of a work, not sure if it is worth the effort.

Today we released Stubbles 0.13.0. This release is a major breakthrough regarding integration of the Inversion of Control functionality. All web applications build with Stubbles can now be created via our Inversion of Control features, resulting in less code for the same power. In Stubbles this means we were able to throw away around 200 lines of code without loosing any functionality. Moreover, we got only slight performance penalties regarding runtime in our applications (around 0.01 seconds more), but experienced less memory usage (up to 512 K) especially in situations were we heavily relied on XJConf configurations before.

Beside this the release contains bugfixes and feature improvements. As always take a look at the changelog. However, don't look too much into our current documentation, it still needs to be updated to reflect the latest changes.

Books, tutorials and other design pattern featuring articles often tend to present the Singleton Design Pattern as the first one. This is for two reasons:

• The Singleton is a very easy to understand design pattern, even for developers new to design patterns or relatively new to the object oriented world.


• The Singleton solves a problem that 99% of these developers have, namely to provide a global access point to some class they make use of everywhere in their application.

However, the Singleton design pattern is fundamentally flawed. This is nothing new and is discussed amongst developers since some years now (just search for "evil singleton"). The Singleton violates several rules of good object oriented design. Code using the Singleton class depends on that class. It is not usable without this class, which in turn makes the client code hard to test. The client code is not programmed against an interface but against a concrete class, though promoting tight coupling between the client and the Singleton, instead of the desired loose coupling. Additionally, classes implementing the Singleton pattern itself are hard to test. Singleton just replaces a global variable and hides it in a class - the global state stays in your application. So, when everybody agrees that global state is bad and that its appearance as Singleton implementations does not make the code any better, why is the Singleton design pattern so often used then? Continue reading "How to get a Singleton right"