Tobias Schlitt - a passion for php

Jeff Moore posted an article on procata.com about getters, setters and real properties. I fully agree with him. Especially the usage of interceptors (__get()/__set()/__isset()/__call()) makes your API a lot more readable and comfortable, while maintaining the purpose behind getters and setters: Checking the correctness of values assigned to a property and wrapping around retrieval mechanisms for a property. I personally call the way of maintaining value-correctness for properties through interceptors virtual properties, which fits quite nice I think.

In eZ Components we make heavy use of this methodology, especially with our option classes. This allows nice looking code like:

While the $dialog object ensures that it's $options property holds nothing but instances of the option class. The latter one ensures, that its $text property has a correct value at any time. If this is violated anywhere, an exception is thrown. I think this is much more intuitive and comfortable than

If you are interessted in this topic, you should buy the upcoming issue of the German "PHP Magazin", which will contain an article about these techniques and some more advanced.

During my current exam phase I'm working on some tiny private project to relax after learning. In there I'm using a main controller class, which implements a singleton pattern and initializes several sub-controllers while being created. The singletons purpose is, that the other controllers can access to main controller and its functionality whenever they need, without storing a reference each. The code for the singleton looked about like this:

What I experienced last night was quite annoying: Instead of my little app starting as usual, it spit out error over error in an endless loop. A few debugging minutes later, I found the suspicious code piece in one of the sub controllers:

Basically, the sub controllers constructor accessed the main controllers singleton method, which is quite the purpose of it. But since the main controller itself did not finish its constructor, yet, the singleton method did not find a valid instance and started creating a new one. This step again created a new instance of tsSubControllerX and so on. I simply moved the construction code of the main controller into a new initialization method, so that the instance is ready before the sub controllers get instanciated.

So, whenever you mess around with lots of nested objects and a singleton, beware of this (absolutely logical) issue. I guess some of you already shared this experience, although in PHP web application environments you usually avoid such deeply nested object structures, but you possibly don't in other environments. ;)

Jakob (a good friend of mine from the PHP UG Dortmund) has written a bash script to create class graphs (non UML conform, but what shalls?) from a PHP source directory. The resulting SVG is generated through GraphViz. He just ran the script on the eZ components. Here is a small excerpt:

Quite cool, I think, and it already helped us a lot to find inconsistencies in some other projects.

Read more on Jakobs blog (which I'm just adding to the Planet).

The october issue of the International PHP Magazine has been published, including "The PHP OO candy store", an article about PHP5s cool OO features and SPL. The article looks cool and I was really suprised to see that it became the cover story. :)

If you are interessted in the topic, you should also visit our session on that topic at the International PHP Conference in Frankfurt next month!

As promised a while ago we'll have a bunch of presentations during the next PHP usergroup meeting in Dortmund. Sadly the date for this event was been moved several times, mainly because of my rare time in the past weeks (thanks guys!). But now the time has come:

Thanks a lot to eZ Systems for sponsoring a location and equipment! Find your way to eZ in Dortmund.

We will have talks on the following topics:

• OOP Basics
  • An introduction into object oriented development.
• OOP Patterns::Toby
  • What are patterns? What aren't they? Some examples...
• XML
  • Sense and use of XML.
• PHPTAL
  • The concept of template engines on the example of PHPTAL.
• DB Basics
  • Database design, normalization,...
• DB Abstraction
  • The sense behind database abstraction and how to do it.
• RegEx
  • The magic behind working with text.

Every talk will be about 30 to 45 minutes and each is held by a member of the PHP usergroup Dortmund.

Would be cool to see some more faces there beside the usual suspects. :)

Yesterday evening was the second meeting I attended of the PHP user group Dortmund. Sadly we've only been 5 people, although there are currently 12 members on the mailinglist. Since we wanna start some kind of useful project with the group members (what project this will be is not ready for the public, yet) and have a huge variaty of states of knowledge in the group, we decided to have an educational session in our next meeting. All of the 5 attendants from yesterday took a topic to prepare a little presentation (30-45 minutes) for the next meeting (in 2 weeks, 5th of May).

I think we picked up some pretty interessting stuff where every member can learn a bit of. The goal is, to provide the basic concept behind a topic to everyone and give hints on further info on the web. The agenda (until now) looks like this (not in a specific order, yet):

• XML (basics)
• OO (basics)
• OO (patterns)
• Templates (PHPTAL)
• DB abstraction (MDB2)

The sessions are all in German language. If you live near Dortmund (or even more far away, I can organize a space for sleeping), feel free to attend or even better propose a session!

phpPatterns introduces a new pattern example on the (IMHO) most redundant software implementation world wide. It implements the "Hello world!" tool (which is a common way to start learning a new programming language) using a MVC pattern in PHP. In my opinion it shows pretty well, how much overhead OO development adds to small software implementations. By the way, it would be definitly interessting how many implementations of "Hello world!" exist on the internet. To give a approximation of that: Google finds about 1,010,000 results for "Hello world!" in it's index...

The big question for PHP5 currently is the discussion around the new dual-syntax system, which allows extensions to be used with a procedural and an object oriented interface. The problem is, that PHP usually uses "_" to devide parts of a function name, where most OO languages (e.g. Java, C#,...) use studlyCaps to divide method name parts. And this is the common way in OO programming with PHP, too (as we from PEAR defined once upon a time...). There was (and I guess already is) a big discussion on the PHP internals mailinglist about that issue and PHP internal developers ran into a heavy guerilla war about that issue. John Coggeshall recently called for comments from the PHP userland on his blog, what I guess is a pretty good idea, since PHP users will have to live for a long time. In my personal opinion, PHP's OO interface should stick to the standards which were defined by PEAR. Usually PEAR follows inventions of PHP, the PHP guys now should one time follow PEAR. In general the "foo_bar against fooBar" discussions seems to result in a matter of personal favor. There are many arguments for and against each style, but I guess the most effective argument is what users want. IMHO, most OO PHP users should be used to the studlyCaps way and for that PHP itself should use it. No matter if methods then do not look like functions, but indeed, they aren't the same. But take your own picture on John's Weblog, the PHP internals thread and your personal experiences and leave a comment here or on John's blog.