Sunday, February 25. 2007
 |
 |
 |
 |
Wishlist pt 3 opposed: ... Posted by Frank Kleine
in
Planet PHP at
14:38
Comments (0) Trackbacks (0) |
 |
 |
 |
 |
Wishlist pt 3 opposed: specifications instead annotations
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.
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
|
|
|
|
My wishlist for PHP 6, pt3: Annotations Posted by Stephan Schmidt
in
Planet PHP at
10:59
Comments (5) Trackback (1) |
|
|
|
|
My wishlist for PHP 6, pt3: Annotations
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"
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
|
|
|
|
My wishlist for PHP 6, pt2: Namespaces Posted by Stephan Schmidt
in
No Stubbles, Planet PHP at
20:50
Comments (10) Trackbacks (2) |
|
|
|
|
My wishlist for PHP 6, pt2: Namespaces
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.
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
|
|
|
|
Wishlist pt1 extended: more type hints Posted by Frank Kleine
in
Planet PHP at
13:19
Comments (4) Trackbacks (0) |
|
|
|
|
Wishlist pt1 extended: more type hints
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"
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"
Monday, February 19. 2007
|
|
|
|
My wishlist for PHP 6, pt1: The ... Posted by Stephan Schmidt
in
No Stubbles, Planet PHP at
19:45
Comments (20) Trackbacks (2) |
|
|
|
|
My wishlist for PHP 6, pt1: The 'object' type hint
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()?
class Processor {
public static function processObject(object $obj) {
echo get_class($obj) . "\n";
}
}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:
class Foo{}
Processor::processObject($foo);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()?
Calendar
| February '07 |
|
|||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | ||||
Categories
Quicksearch
Blogs we read...
Syndicate This Blog
Blog Administration
