Sunday, February 25. 2007
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.
Sunday, February 25. 2007
Porting JavaDoc comments to PHP was one of the best things, that ever happened to to PHP4. But like in Java 4, the DocBlocks in PHP evolved from plain documentation to a feature that adds meta information to classes, methods, properties and variables. IDEs, like Zend Studio, use the @var tag to enable type hinting for method return values, which would not possible without the DocBlock, as PHP is a dynamic languages. Furthermore, there are projects like Services_Webservice or SCA, which add custom tags to the docblock to mark a method or class as a service and allow you to generate WSDL and a full-blown webservice server without the need to write additional code.
In Stubbles, we are taking the same approach to add meta-information to our classes but on a more generic level. Through our extended reflection API, we offer the ability to add annotations to classes, properties, methods or functions. Continue reading "My wishlist for PHP 6, pt3: Annotations"
Tuesday, February 20. 2007
I won't go into detail here, as this topic has been discussed a thousand times on internals. Although prefixing all of your classes works, it still is a PITA. In Stubbles, we are prefixing all our classes with stub, which is fine, as it is a kind of funny prefix, but there are some cases, where this really sucks.
In our implementation of annotations (stay tuned for a tutorial on annotations), every annotation is converted to an object. In our first implementation, the class name had to be the same as the annotation name, but this leads to annotation names that aren't that beautiful to read The XMLSerializer component allows you to use the annotation @XMLTag to specify how an object should be serialized to XML. But the classname XMLTag should not b used as everybody could imagine a future xml extension grabbing the class name. To overcome this drawback, the annotation parser will pre- and postfix the annotation names, so the annotation @XMLTag loads a class called stubXMLTagAnnotation. Namespace support would help us get rid of these little annoyances, as we could import the XMLTag class from the package net.stubbles.xml.annotations. So unless someone comes up for a good reason against namespaces, they will hopefully be part of PHP 6.
BTW: Please spare me the "PHP is not Java" comments, as I already know this.
Tuesday, February 20. 2007
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:
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
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"
Monday, February 19. 2007
I was very pleased, that PHP 5 introduced type hints, although they are not available for primitives like string, int, boolean, etc. Still, I'd like to see the object type hint introduced in any future version of PHP that allows me to specify, that a method or function only accepts an object, regardless of the type of the object:
Currently you always have to specify a class or interface name, but I can't see, why this is needed. In Java, this is no problem, as they have a common base class for all of their classes, which is not the case with PHP. So when trying to call this method with an object like this:
you get the following error:
Catchable fatal error: Argument 1 passed to Processor::processObject() must be an instance of object, instance of Foo given, called in test.php on line 14 and defined in test.php on line 6
The reflection extension lets us do a lot of funky stuff without knowing anything about the passed object, so I can't see a reason why this feature should not be implemented. If this already is possible in PHP, please let me know. If not, I hope that Marcus Börger is reading this entry and will implement this for PHP 6 . And yes, I'm well aware, that this might create some problems if anybody has a class named Object, but please don't start another namespace flamewar (although namespace are one of my other wishes for PHP 6).
And while we are talking about it: What about a ressource type hint, that will only accept ressources, that can be processed by functions like fread() and fclose()?
Saturday, February 17. 2007
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.
Friday, February 16. 2007
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.
Thursday, February 15. 2007
Today you are witnessing the dawn of a new time. The Stubbles developers finally started blogging. Expect to find tutorials, thoughts about new features or just musings about PHP in this blog.
To learn more about Stubbles, either wait for more blog entries or visit the development site.
« previous page (Page 1 of 1, totaling 8 entries) next page »