Dan,
I've added a note about special annotations to the "future scope"
section, naming the memoization-annotation as an example.
Benjamin,
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 <kont...@beberlei.de> wrote:
>
>
> On Sat, May 14, 2016 at 1:48 PM, Rasmus Schultz <ras...@mindplay.dk> wrote:
>>
>> 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.
>
>
> 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.
>>
>>
>> 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
