RE: [PHP-DEV] Re: Annotations in PHP7

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