I am not arguing against the RFC nor the feature itself, on the contrary, I like it. I just do not like certain aspects and design decisions of it; that is all.
Configuration and AOP are the best usecases for annotations and those
should be stressed in the RFC. They are not mentioned at all!
Another usecase that I am missing completely is the usage of it for
documentation and static code analysis. I already mentioned the /throws/
annotation, this could help e.g. IDEs to warn you better about uncatched
exceptions form methods you call.
DbC is a possible usecase but better implemented at language level. The
RFC could mention the possibility of it. However, right now it is the
sole usecase beside the not very PHP applicable `<<inline>>` and
`<<jit>>` examples.
You see, this is more a problem of the RFC text and not of the feature. ;)
Another think I complained about is the proposed syntax because it makes
annotations look like function calls, which they simply are not and will
not be. The syntax is misleading and a possible built-in functionality
of reactive annotations (not saying we need them) at the language level
for userland is blocked. I know I just repeated myself.
The extension you mentioned works just fine without the brackets.
@invariant CONDITION;
class A {
@ensure CONDITION;
@require CONDITION;
function f(){}
}
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
