I've added a note about special annotations to the "future scope"
section, naming the memoization-annotation as an example.


I don't think you mean "out of scope" of what 80% want, I think you
mean "beyond the scope"?

I think this will definitely cover what 80% want to achieve, and
possibly a lot more - possibly new and useful patterns that we can't
even predict.

On Sat, May 14, 2016 at 3:41 PM, Benjamin Eberlei wrote:

On Sat, May 14, 2016 at 1:48 PM, Rasmus Schultz wrote:

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.

Every proposal before was about annotation/attributes as metadata for code.
Your proposal makes them executable functions instead (nameless, attached to
code blocks).

I think this is just way out of scope of what the 80% want to achieve with
this feature.

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
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 <kontakt@beberlei.de>

On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz <rasmus@mindplay.dk>
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
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
annotations to be context less.
You should add to the RFC examples of what is happening, if you do
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

function () {
return php-expression;

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

"Annotations that do require context should explicitly ask for that
- 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 | 9 of 25 | next ›
Discussion Overview
groupphp-internals @
postedMay 13, '16 at 12:11p
activeMay 17, '16 at 6:39p



site design / logo © 2018 Grokbase