On 4/25/2016 10:04 AM, Dmitry Stogov wrote:
>
>
> On 04/24/2016 11:24 AM, Fleshgrinder wrote:
>> 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. ;)
>>
> Looks interesting, but try to think where the "annotation deprecated"
> should be declared,to be visible in every compiled script, when the
> corresponding code should be called (in what context), what if we need
> to do something at compile-time? Single answers to these question are
> going to be great for "deprecated" use case, however they will limit
> usability for other cases.
>
> Thanks. Dmitry.
>
Reactive annotations would have their limitations, e.g. calls to the
reactive annotation function only happen during runtime and any attempts
to perform something at compile time directly results in an engine
error. It limits their use cases but allows interesting ones at the same
time.
Another approach could be to allow registration of reactive annotation
functions at runtime, this would make it even more useful. Of course
that would mean that the function is only called for each encountered
annotation at runtime after it was registered. However, such a
limitation is pretty much the same as we have it for any other function
right now too.
class User {
public function hasRole($right) {
if (false) {
throw new InsufficientPrivileges;
}
}
}
$user = new User();
register_annotation('Framework\Role', [ $user, 'hasRole' ]);
class Controller {
@Framework\Role('admin') public function editAction(){}
}
// ENGINE (pseudo code)
array registered_annotations = [];
void register_reactive_annotation(annotation, callback)
{
registered_annotations[annotation] = callback;
}
void reactive_annotation_call(annotation, ...arguments)
{
if (annotation exists in registered_annotations) {
call registered_annotations[annotation](...arguments);
}
else {
log_info("Unknown reactive annotation %s", annotation);
}
}
However, this is a story for another RFC. It is only important because
usage of the brackets in the current RFC would make such a feature more
complicated to implement.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
