Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92710
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 65.55.169.108 as permitted sender)
To: <internals@lists.php.net>, Sara Golemon <pollita@php.net>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAESVnVrNqpqsTUCdHiQi8j3d4KVz8ZqRh6pEVJegR-EsmFN3_g@mail.gmail.com>
 <571BA0F0.2030400@fleshgrinder.com> <571C82A7.2060706@fleshgrinder.com>
Message-ID: <571DCFA5.1090201@zend.com>
Date: Mon, 25 Apr 2016 11:04:53 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <571C82A7.2060706@fleshgrinder.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2016 08:05:07.8428 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1783
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: dmitry@zend.com (Dmitry Stogov)



On 04/24/2016 11:24 AM, Fleshgrinder 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.
>
>    $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() {}
>
> 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. ;)
>
Looks interesting, but try to think where the "annotation deprecated" 
should be declared,to be visible in every compiled script, when the 
corresponding code should be called (in what context), what if we need 
to do something at compile-time? Single answers to these question are 
going to be great for "deprecated" use case, however they will limit 
usability for other cases.

Thanks. Dmitry.