On 04/24/2016 03:33 PM, Fleshgrinder wrote:
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(){}
}
The proposed by you "@..." syntax just won't fit into PHP grammar,
because @ used as silence operator.
Attribute, syntax is taken from HHVM. I don't see a big reason to
introduce more fragmentation into PHP world.
Personally I don't see "foo(a,b,c)" as a function, I see this as a
predicate.
It's possible to extend RFC with additional use-cases, but the longer
the RFC the less people read it.
Thanks. Dmitry.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
