In his latest post Jake Bell talks about why he thinks annotations in PHP are a bad idea (not the concept of them, but how developers are currently using them. He's in favor of officil support though).

Both the Symfony 2 and Doctrine 2 libraries and components make liberal use of what have come to be called annotations - special code comments, usually prefixed with an @ that are actually interpreted by the application and affect its functionality. [...] This trend needs to die.

He points out that the use of code comments like this isn't a good practice and applications should never have to rely on them for functionality. He mentions issues with syntax/language functionality (can't use "php -l" on them, can't var_dump an annotation) and that it makes it more difficult to read and interpret the code. He includes an example from Ruby of an alternative and a possible solution in PHP involving a static "mapping" variable.

Karsten Deubert has a recent post to his blog looking at annotations in Zend Framework applications to enhance functionality already in the framework.

Recently I had the idea to influence Controller Actions with annotations but discarded it with thoughts like "In PHP I will have to use reflection and some black magic to get this working which will have insane performance hits for my applications"... until I set everything up to see that it costs just 1-2ms in average per request without any form of caching.

He includes a few bits of code to show a simple annotation example (setting a layout) and the controller plugin that performs the translation. In his case, it's hard-coded to look for the "@layout" annotation in the docblock comment, but it'd be relatively trivial to extend it to a more full-featured version.

Rafael Dohms has an interesting new post to his site today looking at a library he's developed (inspired by the Symfony Validation library) to help filtering values with rules defined in annotations.

PHP does not have native Annotations support, however many projects have been using doc blocks to add value and semantics to code, like PHPUnit, Doctrine and Symfony. The Doctrine did a really good job in making available a Annotation parser kit, which allows you to bring the power of annotations into you own project. This opens up a few possibilities.

He shows the current use of the Validation library with a sample check of a $name variable for "not blank". His tool, DMS, extends this functionality and gives you access to both custom filtering methods and standard PHP functions to filter the resulting variable value. He includes an example showing two variables with filters StripTags, StripNewlines and Trim as well as the code to execute the filtering. You can get the library either ready to integrate with Symfony/Doctrine or as a standalone tool.

Fabien Potencier has posted another in his "getting better" series looking at the features that are included in the Symfony2 framework. In this new post he talks about the improvement annotation support.

Later today, I will release Symfony2 beta2. But first, I wanted to talk about a big change that landed into master yesterday. As you might know, Symfony2 uses annotations for Doctrine mapping information and validation configuration. Of course, it is entirely optional, and the same can be done with XML, YAML, or even PHP. But using annotations is convenient and allows you to define everything in the same file.

Two new bundles were added, SensioFrameworkExtraBundle and JMSSecurityExtraBundle, that let you use annotations in the controller for configuration. Examples of this new feature are included in the post giving the configuration settings a more "native" feel.

Gonzalo Ayuso has a new post to his blog looking at some of the recent work he's done with PHPDoc and annotations to create "function decorators" in his code.

The idea is to solve the same problem I had when I wrote the previous article. I want to protect the execution of certain functions in a class to only being executed if the user is logged on. [...] The solution with interfaces is clean and simple (no extra libraries need and no reflection need too). The problem is that I can use it only for all the functions of the class.

He gives an example class with four different methods (one with annotations) and his annotation parsing class that runs the predispatch and postdispatch methods based on those annotations. He also shows another examples using an abstract class.

On the Genius.com blog today there's a new post from Bill Hewett looking at some of the advanced notations you can use in your unit testing (directives in comments starting with "@").

PHPUnit, borrowing a handy feature from Java's JUnit testing library allows you to use certain directives beginning with "@" in comments of your test or application code to access test-related functionality. These directives, known as annotations, even expose features not otherwise accessible to PHPUnit users.

He looks at a list of eight including @assert, @dataProvider and @test as well as some of the new ones coming in PHPUnit 3.4.

On the PHP::Impact blog today there's a new post showing how to use annotations in your application's code that can be used by the Addendum library.

Annotations provide data about a program that is not part of the program itself. They have no direct effect on the operation of the code they annotate. In PHP, annotations can only be read reflectively at run time.

They allow you to document, with meta-data, information about the classes, methods and variables inside the script. They show three of the annotation types - a marker, a single-value and a multi-value.

In his latest post, Sebastian Bergmann shares some information about an extension for the Reflection API included in PHP 5.

The Extended Reflection API enhances PHP 5 by providing access to type information and annotations that are embedded as doc-comments into the sourcecode.

Processable additions to the source code enable a wide range of new applications in general, and Web Services and Aspect-Oriented Programming in particular.

The wiki page for the project shares the difference between the two, including graphics to help show how they tie in together. There's even some pseudo code to get you started with the different class types, a mapping out of the API.

Building on this article from the IBM developerWorks site talking about "Five Common Database Problems", Kristian Kohntopp adds in some of his own comments for the five common problems from his perspective.

My experience in the field differs slightly from his observations, and so I thought a few annotations may be in order.

Each of the five in the list have large explainations following them, with slightly different takes on what was said before on the subject and sometimes even a few agreements here and there.