Re: [RFC] PHP Attributes
| From: | Fleshgrinder | Date: | Sun, 24 Apr 2016 12:33:34 +0000 |
| Subject: | Re: [RFC] PHP Attributes | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-92689@lists.php.net to get a copy of this message | ||
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
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
<<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
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc