Hi Dmitry,

In my mind, annotation syntax was one level lower, dealing with strings of 
unknown syntax, not PHP expressions. Something like :

'*' <whitespaces> '@' STRING free-string-up-to-eol

This supports :

* @requires $a > 0

But also :

* @statement INSERT INTO ?? VALUES (13, 'Phoenix', 'AZ', 33, 112)

Using Reflection, the application would get an array of (STRING => array of 
<free-strings-up-to-eol>) in order of appearance and that's all for the 
annotation layer. Then, the client has the responsibility to interpret the 
strings the way it wants.

Even if it is a valid PHP expression, getting it as a string is not a problem. 
DbC, for instance, would get the string, eval() them and error if one of them 
evaluates to false. Performance must not be a problem with annotations. This is 
what makes it suitable for DbC or offline metadata.

If we restrict it to a PHP expression, you need to interpret it at compile 
time, which makes the process more complex. I must admit I don't understand the 
reason, as the only one I see is performance. And I am totally out of sync with 
suggestions to include namespaces, nested annotations, or using class constants 
in expressions. I even feel incomfortable because it's just 'PHP code, but 
elsewhere'. I don't see the use case.

About the syntax, I'm probably faulty there, but I don't understand why we 
cannot use doc blocks. That's easy to parse at compile time, the API is easy to 
define, the parser already parses them, and everyone is already using that. 
Existing applications like doctrine just miss the API to use it in a cleaner 
way but it would be 100% compatible. Actually, I saw several people refusing to 
consider doc blocks as annotations but I was never given the reason why. So, I 
am just curious.

Anyway, I don't like the OO features people want to add everywhere. They can 
get strings and inject them to OO, but that's not the role of the annotation 
layer, IMHO.

I definitely prefer the KISS approach.

Regards

François



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to