Thank you for your comments!


I have removed the comment about annotation expressions executing in
an empty closure, since this example was clearly confusing, and I have
tried to clarify the fact that annotation expressions execute in an
empty scope. To be clear, annotation expressions are *not* closures,
and they do not accept arguments - there is no reason to complicate
the concept of annotations by introducing an implied scope, when you
can introduce one explicitly, for example:

class Validation {
     private $validate;

     public function __construct(callable $validate) {
         $this->validate = $validate;

     public function validate($instance) {
         return call_user_func($this->validate, $instance);

<< new Validation(function (User $user) { return false !==
filter_var($user->email, FILTER_VALIDATE_EMAIL); }) >>
class User {
     public $email;

Of course, you could just as well do this with an interface - as it
the case with most examples I can think of.

If you can think of a meaningful annotation that actually requires
context and can't be implemented in a better/safer/cleaner way with
abstraction, please post? I'd like to add an example, but really have
never seen one that can't be solved better without annotations.

Love the simplicity of the RFC, but I can already see people doing terrible things with it
Every language lets you do terrible and great things - I don't believe
in putting up roadblocks and complicating the language that prevent
people from learning.
TBH, I'd rather just allow a constant array (with constant expressions only), and that would be good enough :-)
I don't agree with the idea of crippling a language feature to prevent
beginners from making mistakes - when doing so would also prevent
static analysis and block experienced developers from doing useful
things with objects.

Davey and Mathieu,

Annotations can be "named" by using classes. Per the RFC, defining or
enforcing a rule about allowing only one instance of the same type, is
not a feature.

Hack's memoize is an annotation for the language interpreter itself -
that's beyond the scope of this RFC, but could be implemented in the

Your third question is answered by the RFC here:
Annotation expressions are not evaluated until reflection is invoked, and are evaluated only once and internally memoized upon the first call to getAnnotations().
Thank you for your input so far!

The RFC is 0.2 with the last updates based on your feedback - I would
like to add a suitable case example for annotations that require
context before I'd say this RFC is 1.0.

If anyone can point at a real case example using Doctrine Annotations
(or anything else) please do!


On Sat, May 14, 2016 at 4:38 AM, Benjamin Eberlei wrote:

On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz wrote:

Dear Internals,

I'm announcing a simplified RFC for annotations:


It's an alternative to the proposed Attributes RFC and the (2010)
Annotations RFC.

I'm attempting with this to describe a feature that is closer to the
language than what is proposed by the Attributes RFC, by permitting
the use of any valid PHP expression as an annotation value.

Where the Attributes RFC proposes new syntax for what is essentially
arrays, this proposal instead permits you to use actual arrays, e.g.
without inventing any new syntax. It also allows you to use values of
any other type, including objects. This makes the proposed feature
more immediately useful, with a minimal learning curve.

The attributes RFC actually does not specific syntax or arrays, but either a
scalar (number, string) or an ast\node.

A proposal for arrays *would* actually be "closer to the language" as you
describe it.
Compared with the old Annotations RFC (and Doctrine Annotations, etc.)
this proposal does not attempt to define or enforce any rules about
what annotations are, permitted usage, inheritance rules, etc. -
instead it adds a very simple language feature upon which the
community may choose to build (and evolve) facilities that implement
additional rules and logic.

My hope is that, if we can agree on something very small and simple,
we can defer the more opinionated discussions about rules and logic to
the community.

In my opinion, language features should be simple, and consistent with
the language - I believe the way to do that, is to avoid discussions
about how such as facility should be used, and instead focus on how it
should work. There is a lot of opinion built into the old Annotations
RFC, and into Doctrine - features that attempt to dictate how the
feature should be used. I don't believe the language should dictate
what is or isn't correct or appropriate use.

Please review and comment.

I see you took my question about context from the other thread and defined
annotations to be context less.
You should add to the RFC examples of what is happening, if you do access
context, for example access to undefined variable notices:

class Foo {}

$refl = new ReflectionClass('Foo');
// PHP Notice: Undefined variable: x in Command line code on line 1

Still this is imho a weak point of your RFC. You already stated that a
"simplified annotation" the way you see it is the expression wrapped in a

function () {
return php-expression;

So if an annotation is a function/closure that belongs to its target (class,
property, function, method, ...) then why wouldn't there be a way to specify
The RFC should give an answer to that. The statement you add doesn't make
sense without examples. How does dependency injection even work, when you
don't have a context?

"Annotations that do require context should explicitly ask for that context
- for example, you could use an anonymous function, a callable, or an
anonymous class, to provide context via dependency injection."

Rasmus Schultz

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 25 | next ›
Discussion Overview
groupphp-internals @
postedMay 13, '16 at 12:11p
activeMay 17, '16 at 6:39p



site design / logo © 2023 Grokbase