Planet PHP

Seldom in a life of a developer it comes to the point where a bug can be fixed by a feature addition. This February, it happend to vfsStream. A user reported a bug where overwriting an existing vfsStream file with new but smaller content replaced only portions of the file, leaving the rest in place instead of truncating the old content before writing the fresh content. After some investigation it turned out the best fix for the problem was to implement the long scheduled feature issue 7. Thought, said, done. So today I shipped vfsStream 0.6.0 including complete support for for $mode param when opening files.

While I was at it, I added support for the $options param as well, it now evaluates whether STREAM_REPORT_ERRORS is set and acts accordingly when opening a file.

Unfortunately there are bad news as well. Due to another issue I found out that ext/zip does not work with vfsStream, and that there is no way to add support for it in vfsStream. Maybe if someone with slightly more C skills than me (which are equal to zero) might want to look into this problem for a better explanation, as I can only assume that it's due to ext/zip not supporting userland stream wrappers.

If you like the new additions get the new release.

Today I shipped vfsStream 0.5.0 which brings a new feature thanks to the efforts of Benoit Aubuchon: vfsStream now supports the rename() functionality which allows you to write test cases using vfsStream for methods that rename files. Another patch of him was to change the stat() call to respect the STREAM_URL_STAT_QUIET flag.

One more new feature is the added support for . as current directory alias so that vfs://foo/. resolves to vfs://foo - this allows to use file_exists($dir . '/.') as workaround for the failing is_executable() call on directories, as described in the comments to the is_executable() documentation in the PHP manual. Of course this raises the question if vfsStream will support .. as well - if somebody takes the time to create a patch I will incorporate this. I did not look into this issue further, but I guess it might involve recursion and a more advanced parsing of the vfs URL to make it work properly, as there might be cases like vfs://foo/bar/baz/../../dummy.

So grab the release and make use of the new features, if you like to.

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.

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.

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.

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"

Annotations are a really helpful feature in present-day development. An annotation is a special form of syntactic metadata that can be added to source code elements such as classes, methods, properties and parameters. They do not affect the program semantic directly, but can be used by tools and libraries to handle such annotated code in a certain way. Examples for such usage are marking classes or methods as accessible via web services, marking methods as unit test methods, or to define how an object should be persisted.

Annotations are mainly known from the Java programming language, and since Java 5.0 annotations are a language feature. More important, these annotations are accessible at runtime, which allow various new meta-programming approaches where the domain object stays very clean and does not have any references to the handling code, i.e. when persisting domain objects or rendering them into XML.

Today I want to take a look on the state of annotations in the PHP world. PHP itself does not offer such a feature, so we have to take a look at userland implementations. Such implementations are possible using the reflection API introduced with PHP 5. When looking at userland implementations one has to differentiate between specialised and generic implementations. Continue reading "State of annotations in the PHP world"

As requested I did my homework today and tested Stubbles against PHP 5.3 alpha1. Well, actually alpha2-dev, but that should not make that much difference. I don't know whether 5.3 is PHP on drugs, but runtime of our unit tests dropped from around 45 seconds with 5.2.5 to around 15 seconds on 5.3. Down to one third! This is really impressive. We will have to see how 5.3 will perform with the applications itself, but this raises expectations.

The other good news is that we only had two forward compatibility issues, which I instantly fixed. One of them was in a unit test and not relevant to the framework itself, the other had to do with a new check on callbacks which now forbids using private methods in callbacks, even if the callback is triggered from inside the same class.

Update
At first I thought of just another check for the callback thing, but the comments lead me to reinspect the code. I now think it might really be a bug in PHP 5.3, therefore I created a small script to reproduce the effect, see repository. I sent it it to Lars, who will make sure it gets fixed in the final release.

Ìn case you are interested in a new job and speak german: Read on after the break. Continue reading "Searching for a new job?"

Just stumbled over a proposal for traits in PHP, proposed by Stefan Marr. Being a bit sceptical at first I came to the conclusion that this would be a really useful feature - and save us a bunch of doubled code in Stubbles. After reading the RFC until the end I noticed that I saw a similar concept some weeks before in Java: Qi4J tries to achieve the same, but requires very much code to get this done. As a language construct within PHP it would be very easy to do the same, but easier to learn and to use. Beside some keyword issues (the RFC uses "use" as keyword, but this will of course conflict with namespaces) I'm wondering what this will have an impact on reflection - the RFC stays unclear about this. What do I get when reflecting a method from a trait, or a method in a class that originally comes out of a trait?

However I'm not very confident that this feature will make its way into PHP - maybe I've read to much internals...

At least if it comes to internal classes. If you try to get informations about parameters from methods of internal classes - forget that. Examining several internal classes my key findings are: either there is no information about parameters available and the reflection API says the method does not have any parameters, or the information about the parameter is wrong. Some examples I retrieved with the following script:
Continue reading "Do not trust the reflection API"