Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92682
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: <571C82A7.2060706@fleshgrinder.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
	<CAESVnVrNqpqsTUCdHiQi8j3d4KVz8ZqRh6pEVJegR-EsmFN3_g@mail.gmail.com>
	<571BA0F0.2030400@fleshgrinder.com>
	<571C82A7.2060706@fleshgrinder.com>
Date: Sun, 24 Apr 2016 13:36:05 +0200
Message-ID: <CAEPJdum9BdM2B04d6Jp0_YtD=YZa1pPjUD3H5ZC4RRYkw_t1jA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Cc: Sara Golemon <pollita@php.net>, "dmitry@zend.com >> Dmitry Stogov" <dmitry@zend.com>
Content-Type: multipart/alternative; boundary=001a1141d2942c055c05313977ad
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: kontakt@beberlei.de (Benjamin Eberlei)

--001a1141d2942c055c05313977ad
Content-Type: text/plain; charset=UTF-8

On Sun, Apr 24, 2016 at 10:24 AM, Fleshgrinder <php@fleshgrinder.com> wrote:

> The invariant could also be added as an additional branch to the class
> instead of a method, since it would not work like a method.
>
>   class A {} invariant {}
>
>   function f() {} require {} ensure {}
>
> This would also align nicely with closures and anonymous classes, which
> is kind a problematic with annotations.
>

You are way off topic with this imho.

>
>   $A = new class {} invariant {};
>
>   $f = function () {} require {} ensure {};
>
> The only thing that remains that might be of interest to both is
> `@throws` but that was not discussed at all as of yet.
>
>   use Ns\SomeException;
>
>   @throws SomeException
>   function f() {
>
>   }
>
> This is at least how one would expect it to work and it is something
> that should be covered by annotations and not as part of the language.
> The ABNF should account for that:
>
> ANNOTATION    = "@" NAME [ " " VALUE ]
> NAME          = STRING
> VALUE         = QUOTED-STRING / PHP-REFERENCE / EXPRESSION
> QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
> EXPRESSION    = PHP-CODE ";"


> Where PHP references are any of the already possible ones:
>
>   use F\Q\C\N;
>
>   @annotation \F\Q\C\N
>   @annotation N
>   @annotation \F\Q\C\N::CONSTANT
>   @annotation N::CONSTANT
>   @annotation \F\Q\C\N::function()
>   @annotation N::function()
>   @annotation \F\Q\C\N::$variable
>   @annotation N::$variable
>
> I also though some more about function support for annotations and this
> would actually be a nice thing for userland.
>
>   annotation deprecated(Reflection $element, string $message = '') {
>     @trigger_error($message, E_USER_DEPRECATED);
>   }
>
>   @deprecated('because')
>   function x() {}
>
>   @deprecated
>   function y() {}
>

Attributes as proposed by Dimitry are not executing functions, they are
only metadata
that can be retrieved through reflection API. I think a python style
decorator approach
that you propose here, executing functions is not what the different
pro-annotations,
pro-attributes or pro-DesignByContract fractions want/need.

You are proposing something along the lines of AOP, which is an entirely
different beast
in my opinion.


> This would allow users to implement simple and easy reactive annotations
> in userland. Even if this could or should be an extension of the feature
> in the future, it should be thought about know. Simply because the
> brackets make sense if such a feature is to be implemented. ;)
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>

--001a1141d2942c055c05313977ad--