The invariant could also be added as an additional branch to the class instead of a method, since it would not work like a method.
class A {} invariant {}
function f() {} require {} ensure {}
This would also align nicely with closures and anonymous classes, which
is kind a problematic with annotations.
$A = new class {} invariant {};
$f = function () {} require {} ensure {};
The only thing that remains that might be of interest to both is
`@throws` but that was not discussed at all as of yet.
use Ns\SomeException;
@throws SomeException
function f() {
}
This is at least how one would expect it to work and it is something
that should be covered by annotations and not as part of the language.
The ABNF should account for that:
ANNOTATION = "@" NAME [ " " VALUE ]
NAME = STRING
VALUE = QUOTED-STRING / PHP-REFERENCE / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION = PHP-CODE ";"
Where PHP references are any of the already possible ones:
use F\Q\C\N;
@annotation \F\Q\C\N
@annotation N
@annotation \F\Q\C\N::CONSTANT
@annotation N::CONSTANT
@annotation \F\Q\C\N::function()
@annotation N::function()
@annotation \F\Q\C\N::$variable
@annotation N::$variable
I also though some more about function support for annotations and this
would actually be a nice thing for userland.
annotation deprecated(Reflection $element, string $message = '') {
@trigger_error($message, E_USER_DEPRECATED);
}
@deprecated('because')
function x() {}
@deprecated
function y() {}
This would allow users to implement simple and easy reactive annotations
in userland. Even if this could or should be an extension of the feature
in the future, it should be thought about know. Simply because the
brackets make sense if such a feature is to be implemented. ;)
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
