Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93331
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.54 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADqTB_iUDGHXUR5cYUDuzL4XrqJk-Jf0oce_uj6ZUtEYr7fTYw@mail.gmail.com>
References: <CADqTB_i5WL+rzCuFHkRmXsPj16WDc4eWmpAoFmyeuYXvuOP_NQ@mail.gmail.com>
	<CAEPJdunJ-67CqJq2hzvmnEmuOFQRGpxv8iycq3CnocXR4r20vw@mail.gmail.com>
	<CADqTB_iUDGHXUR5cYUDuzL4XrqJk-Jf0oce_uj6ZUtEYr7fTYw@mail.gmail.com>
Date: Sat, 14 May 2016 15:41:12 +0200
Message-ID: <CAEPJdunVsJWkOez3ERdpsKjFx8oxPmWVropZ5n9VKTfKdokpXg@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013c63366dfe9b0532cd8bad
Subject: Re: [PHP-DEV] [RFC] Simple Annotations
From: kontakt@beberlei.de (Benjamin Eberlei)

--089e013c63366dfe9b0532cd8bad
Content-Type: text/plain; charset=UTF-8

On Sat, May 14, 2016 at 1:48 PM, Rasmus Schultz <rasmus@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 <kontakt@beberlei.de>
> wrote:
> >
> >
> > On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz <rasmus@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
> >>
> >
>

--089e013c63366dfe9b0532cd8bad--