If you are interested in learning more about applying common design patterns to your applications and are able to understand German, we have good news for you. Your first chance to get information about pattern driven development from the Stubbles developers is the International PHP 2007 Conference in November, where Frank and I will be giving a half-day workshop on PHP Design Patterns. As Frank wrote last month, we are also giving some more 1-hour talks at this conference.
Your second chance to learn more about design patterns is the new German professional PHP training organized by Wolfgang Drews. The course consists of 12 different sessions, I'll be giving the talks about OO developement and PHP design patterns. Other trainers include Christian Wenz, Tobias Schlitt, Kore Nordmann and Tobias Hauser. The best part about this course is, that is an online training and you do not even have to leave the house. More information can be found at the course website or Wolfgang's blog.
If you prefer to read or cannot afford any of the above options, there still is my book PHP Design Patterns published by O'Reilly.
The built-in Exception class in PHP is total crap. It is an inheritance nazi preventing you from doing useful stuff in your own exception classes. Whoever made its get*() methods final and the trace property private did not thought any second about how exceptions may be used or that people need to implement their own stack trace handling.
The reason I'm ranting about this is that I'm currently developing some classes that will interact directly with an application server and I need to map the exceptions thrown on the application server, delivered over the wire to my application, into my own exception classes. Of course the transferred exception contains a stack trace that I want to show within my application.
But I can not create an exception instance and overload the stack trace with that one delivered over the wire and then throw this exception. The PHP exception class forces me to implement another stack trace in my exceptions, but it is nonsense, because if the exception is thrown and not caught and has no proper __toString() implementation it will just show the senseless stack trace from where it was thrown within my application, not the stack trace from the application server. Instead of reusing existing code the built-in exception class forces me to implement my own stack trace handling, overload the __toString() method and rewrite all stuff to display the correct stack trace as it is known from the native stack trace handling. Additionally I have to remind all developers using my exception that they can not call the default methods to get the stack trace but that they need to use special methods on this exceptions. Not to talk about increased memory usage because the exception contains two stack traces now.
For some reasons I had the need to reimplement PHP's serialize() and unserialize() functions in userland. While the Reflection API would be of great benefit for introspecting objects and grab the values of the object's properties it is not suited for this task - trying to read or set a protected or private property results in an ReflectionException. However, there are some ways to get around this restriction.
Getting the value of protected or private properties is somewhat simple: just cast the object to an array:
public $foo = 'foo';
protected $bar = 'bar';
private $baz = 'baz';
$foo = new Foo();
$fooProperties = (array)$foo;
Now it is very simple to iterate over the array and grab the values of the respective property. Using this it is just a bunch of some more code to reimplement serialize() in userland. Reimplementing unserialize() is a bit trickier, because it is really hard to set protected and private properties (but not impossible).
Probably you already heard of var_export(). Using this function returns a string that can be eval()'d, that is it gives you valid PHP code to execute. This code contains a method call ClassName::__set_state(). Using this magic method you can recreate your object from userland unserialize(). Well, it is not that simple. It gets really tricky with nested objects and as soon as one of the objects you want to unserialize does not contain this method there is no way to set the protected and private properties.
So, whats the lesson from this? If PHP offers possibilities to read the value of protected and private properties (and with some hackish workarounds even to set them) anyway, why just not allow this within the Reflection API? No, "because it allows developers to shoot themself in their foot" is not a valid reason. Developers will always find a way to shoot themself in their foot, regardless of the measures you undertake to protect them.
By the way, it would be really nice if the reflection methods just return NULL instead of FALSE when something is not available. But that is another story about "the PHP way".
« previous page
(Page 1 of 1, totaling 4 entries)
next page » Frontpage