Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92711
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 157.56.110.104 as permitted sender)
To: <internals@lists.php.net>, Benjamin Eberlei <kontakt@beberlei.de>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAESVnVrNqpqsTUCdHiQi8j3d4KVz8ZqRh6pEVJegR-EsmFN3_g@mail.gmail.com>
 <571BA0F0.2030400@fleshgrinder.com> <571C82A7.2060706@fleshgrinder.com>
 <CAEPJdum9BdM2B04d6Jp0_YtD=YZa1pPjUD3H5ZC4RRYkw_t1jA@mail.gmail.com>
 <571CB44C.1000704@fleshgrinder.com>
 <CAEPJdunm-YukXgSV5OWigiWX02Sw9Nz=GvLgJJN4Fq-j-hjZcA@mail.gmail.com>
 <571CBD1E.7020103@fleshgrinder.com>
CC: Sara Golemon <pollita@php.net>
Message-ID: <571DD2A3.2020106@zend.com>
Date: Mon, 25 Apr 2016 11:17:39 +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: <571CBD1E.7020103@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:17:52.9457 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1784
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: dmitry@zend.com (Dmitry Stogov)



On 04/24/2016 03:33 PM, Fleshgrinder wrote:
> I am not arguing against the RFC nor the feature itself, on the
> contrary, I like it. I just do not like certain aspects and design
> decisions of it; that is all.
>
> Configuration and AOP are the best usecases for annotations and those
> should be stressed in the RFC. They are not mentioned at all!
>
> Another usecase that I am missing completely is the usage of it for
> documentation and static code analysis. I already mentioned the /throws/
> annotation, this could help e.g. IDEs to warn you better about uncatched
> exceptions form methods you call.
>
> DbC is a possible usecase but better implemented at language level. The
> RFC could mention the possibility of it. However, right now it is the
> sole usecase beside the not very PHP applicable `<<inline>>` and
> `<<jit>>` examples.
>
> You see, this is more a problem of the RFC text and not of the feature. ;)
>
> Another think I complained about is the proposed syntax because it makes
> annotations look like function calls, which they simply are not and will
> not be. The syntax is misleading and a possible built-in functionality
> of reactive annotations (not saying we need them) at the language level
> for userland is blocked. I know I just repeated myself.
>
> The extension you mentioned works just fine without the brackets.
>
>    @invariant CONDITION;
>    class A {
>
>      @ensure CONDITION;
>      @require CONDITION;
>      function f(){}
>
>    }
>
The proposed by you "@..." syntax just won't fit into PHP grammar, 
because @ used as silence operator.

Attribute, syntax is taken from HHVM. I don't see a big reason to 
introduce more fragmentation into PHP world.

Personally I don't see "foo(a,b,c)" as a function, I see this as a 
predicate.

It's possible to extend RFC with additional use-cases, but the longer 
the RFC the less people read it.

Thanks. Dmitry.