Thank you for your comments!
Benjamin,
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.
Marco,
> 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
future.
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!
Thanks,
Rasmus
On Sat, May 14, 2016 at 4:38 AM, Benjamin Eberlei <kont...@beberlei.de> wrote:
>
>
> On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz <ras...@mindplay.dk> wrote:
>>
>> Dear Internals,
>>
>> I'm announcing a simplified RFC for annotations:
>>
>> https://wiki.php.net/rfc/simple-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:
>
> <<$x>>
> class Foo {}
>
> $refl = new ReflectionClass('Foo');
> var_dump($refl->getAttributes(Foo::class));
> // 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
> closure:
>
> 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
> arguments?
> 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."
>
> greetings
> Benjamin
>
>>
>> Thanks,
>> Rasmus Schultz
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
