Entries by Frank Kleine

Today I saw PHP namespaces in action. Timm Friebe, who backported the namespace patch to PHP5, showed me a namespaced version of the XP-Framework. This was very impressive! We experimented a bit with __autoload() and it was very nice to see that the function is not called on the import but actually when the class is used within the code. Additionally we played around with full and non qualified classnames, with and without the import statement. What I saw looks really promising. Keep your fingers crossed that we will get a PHP5.3 with namespaces!

The Stubbles team is proud to announce the release of Stubbles 0.2.0. This release is another alpha version and contains the basic MVC structure as well as support for JSON-RPC, utility packages for working with datespans, URLs and a cache package. Additionally the build system has been enhanced and a lot of bugs have been fixed. For a complete list of changes see the changelog. The release can be downloaded from our downloads page.

The Stubbles team is proud to announce the release of Stubbles 0.1.0. This release is a first alpha version and contains the basic features of Stubbles like the Extended Reflection API, XML handling with XMLStreamWriter and XMLSerializer, Logging, Event handling, support for filtering and validating user input and session handling. The release additionally contains parts of packages that we announced to be in the next milestone 0.2.0.

Those who are familiar with the XP-Framework may be interested to hear that it is possible to load and use the classes of XP natively within Stubbles. Read on for an example how to do that. Continue reading "Loading classes from the XP-Framework"

In an earlier entry I promised that we will explain why we develop Stubbles. Well, there is a short version of it and a long version.

Short version: for us.
Read on for the long version. Continue reading "Why we develop Stubbles"

Terry Chay made some remarks to my last blog entry about a solution for lazy class loading without using __autoload(). Some of his statements seem like I explained my implementation not good enough leading to wrong interpretations. In this blog entry I'll use some of his statements to take a deeper look into my implementation and show that he has drawed some conclusions which I want to disprove.

He writes:

Frank makes his classes that need to be serialized implement an interface (technically, it is subclassed from his base object). This object has a method (not __sleep) that serializes itself into a special object containing this data along with a string containing the class path. This object is included before session_start and reads the full path name to include the class definition just in time.

This approach violates my central tenet of looking for solutions in practices or functions. He closes himself off to built-in functions of __sleep() and __wakeup() because he is no longer serializing the class itself, he’s serializing a stub object.

That is not correct. To show this I will dig into some technical details of my implementation:

class stubSerializedObject implements stubObject { /** * full qualified class name of the serialized class * * @var string */ protected $className; [...] /** * the serialized class data * * @var string */ protected $data; /** * constructor * * @param stubObject $object the stubObject instance to serialize */ public function __construct(stubObject $object) { $this->className = $object->getClassName(); $this->hashCode = $object->hashCode(); $this->data = serialize($object); } [... rest of class ...]

I have marked the important line. It shows that the object itself is serialized which means that one can still use __sleep() and __wakeup() within the class to serialize. Obviously, there is no parallel architecture for serialization and deserialization, its just wrapped.

You can’t use two frameworks, because in this case they would have conflicting ways of deserializing themselves. If you wanted to use a library from PEAR, you’d be forced to put an adapter pattern in front of it just to get the fucker to serialize.

As it should become clear from what I explained above you can still put any other classes you use (maybe those from PEAR) into the session without worrying about how they should be serialized - it just uses the default serialization mechanism.

$session->putValue('stubblesClass', $stubblesClass); $session->putValue('PEAR_Example_Class', $pearExampleClass);

No need to have an adapter. Our session implementation takes care of the correct handling. And no problem if you use another session class from another framework: in this case you just can't make use of the lazy loading, but still put the object into the session as you do with any other one.

More to the point, not storing classpaths with the serialized object is a Good Thing™. Since the session is most-likely stored across servers (via the memcache best practice), storing class paths with the sessions means the directory architecture has to be shared across servers.

Well, not the whole classpath is stored. Our class loader knows where the classes reside. The "class path" is just the path from there to the correct subdirectory containing the file with the class. Therefore the directory structure can be different on another server, it is just required that the directory structure of your source directory is the same, but the path to the source directory can be different on each server. So there is nowhere a hard path, the stored class path is just a relative one.

In case you use the PHP session mechanism the manual has a warning for you:

If you do turn on session.auto_start then you cannot put objects into your sessions since the class definition has to be loaded before starting the session in order to recreate the objects in your session.

This also applies if you use session_start() but did not load all classes that have been put into the session in earlier requests. This can result in problems if you have a very lazy class loading and do not want to use the __autoload() feature. In Stubbles we do not use __autoload() for several reasons, one of them is that we don't want PEARified class names in style of PACKAGE_SUBPACKAGE_ABSTRACTCLASS_CONCRETEIMPLEMENTATION. I simply don't like them, its one of the reasons why I choose SimpleTest over PHPUnit. But when there is no __autoload(), how could lazy loading work?

A decision made earlier was to have a basic interface for all our classes, called stubObject. Every class implements this interface (of course there is a default implementation). The trick is done with an additional class, which represents a serialized state of the concrete class. Every stubObject offers a getSerialized() method which returns a stubSerializedObject. This contains the full qualified classname and a serialized representation of the stubObject. It also features a getUnserialized() method which will load the class if it has not been loaded yet and then unserializes the stubObject .

Because the stubSerializedObject is always loaded in Stubbles our session implementation can now check if a value to store is an instance of stubObject. If it is, it just stores the return value of its getSerialized() method. On a later request, when the value should be retrieved from the session, the session checks if the instance to return is of type stubSerializedObject - if this is the case it returns the return value of its getUnserialized() method which loads the required class if this has not been done yet.

This approach seems to me even better than using __autoload(): it will load the required classes only if they are really used. If they are stored within the session but the current request does not use it the appropriate class will not be loaded. Very lazy, isn't it?

In part three of his wishlist for PHP 6 Stephan wrote that he would like to see annotations built into PHP 6 directly. I disagree with him about that. Annotations can be done in userland, without any problems. He already gave some examples of projects that accomplished this task. But if you look at them you see that every project has a different solution on how to implement annotations for PHP which leads to the problem that if you use different projects in your own application you have to handle all their ways of treating annotations. Annoying, isn't it?

In my notes to some reactions occured when announcing Stubbles I already wrote about the lack of specifications in PHP, and obviously I'm not the only one who would encourage such specifications. Specifications would solve the problem of different incompatible solutions. They would define interfaces, and all you have to do is programming against this interfaces, leaving the choice of which solution to use up to the user of the application or depending on concrete stuff you are doing. Of course, this is not limited to annotations. It could be applied on everything that can be done in userland.

How specifications can be created and handled has not to be invented, the Java Community Process can give us a lot of hints for that. Such a process, applied to PHP, can as well give us a new way of handling for the PHP internals, but that is up debate for the core developers once such a process is established.

The defined interfaces of those specifications could be part of the Standard PHP Library, where I would like to see more interfaces and less concrete classes as well, so everybody can rely on the interface to be there (because SPL is part of PHP by default). In the concrete example it would also mean less work for the core PHP developers because adding some new interfaces to the SPL should be easier to accomplish than real native support for annotations. However I think this will raise the need for namespaces.

The question about who should handle the process and provide the infrastructure for it is not that difficult. It not has to be necessary Zend or the PHP group like Stefan Koopmanschap suggested, it can be a group of motivated PHP developers as well. The more interesting question is whether such a project would be supported by both of them. It could only be successful if supported by them. I think it would be interesting to initiate and create the process (anyone else interested?), but of course it doesn't make any sense if it doesn't get the support by the PHP group, Zend and other PHP companies and PHP developers.

Yesterday evening Stephan wrote about the object type hint. Coincidentally, while being in my favourite bar, I was talking with Timm Friebe, a colleague of mine, about the scalar type hint:
function bar(scalar $baz) { ... }
This type hint would allow passing integers, floats, strings and boolean values, but no objects, arrays, resources and null values (null would be allowed if you make it function bar(scalar $baz = null) similarly to how type hints work until now).

Having this type hint would have some advantages: you may never pass objects or arrays into this function which will be converted to strings, this will throw an E_CATCHABLE. It also still adheres to the PHP way I believe, because it does not specify the concrete scalar type and lets you the choice about it. Splitting this much more into strings, integers and so on is oversized and would not fit into PHP. (That it would be possible has already been demonstrated by Derick.)

However I think it is not that necessary, but it rounds off the whole type hint story in PHP and would allow doing some stuff with arrays (now I'm going really mad ): Continue reading "Wishlist pt1 extended: more type hints"

Yesterday Stephan announced the Stubblog, and because the blog is included in Planet PHP (which the Stubblog will not be due to their policy to not accept project-only feeds) it forced some reactions which reminds me a bit of Classical Conditioning. And I believe that none of those complaining really read what Stubbles is about.

Yes, PHP will never have something unifying like Rails. But are there really too much frameworks out there? I don't think so. Competition is a good thing. It is about choice, striving for new ideas and combining them in ways no one thought before. I believe that Ruby in the long run has a serious drawback in only having Rails. Because there is only Rails people who don't like it will not start using Ruby because they don't have the choice to use another framework.

But I admit, there is a problem with too much frameworks. Its about specification. PHP has no specifications. The lack of the PHP community to define such specifications will bring a lot more of new frameworks for us in the future that are not compatible. In Java no one complains about competition between frameworks. They have specifications, and frameworks stick to those making it easier to switch between them because they have the same API. Yeah, I know PHP is not Java. It should not be in the language. But it should learn from their way of defining specifications. As long as this does not happen the rants about YAF™ (Yet Another Framework) will not lead us anywhere.

Enough ranted. In a forthcoming blog entry we will write why we develop Stubbles and did not stick to another framework. Stay tuned.

Some minutes ago I finished the documentation about the session component of Stubbles. It explains how to use and extend the session classes. Additionally it has some notes about the measures to protect session integrity that are part of the base session implementation. Don't hesitate with comments on how to improve the documentation or the implementation, especially on the part of protection.