Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92715
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 207.46.100.104 as permitted sender)
To: Dan Ackroyd <danack@basereality.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CA+kxMuSxAWkNXai0kgW1b1anSohn63frjw76puo1PyCB=xWx=g@mail.gmail.com>
CC: internals <internals@lists.php.net>
Message-ID: <571DD85B.50500@zend.com>
Date: Mon, 25 Apr 2016 11:42:03 +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: <CA+kxMuSxAWkNXai0kgW1b1anSohn63frjw76puo1PyCB=xWx=g@mail.gmail.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:42:17.8162 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1787
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: dmitry@zend.com (Dmitry Stogov)



On 04/24/2016 07:03 PM, Dan Ackroyd wrote:
> On 21 April 2016 at 22:13, Dmitry Stogov <dmitry@zend.com> wrote:
>> Hi,
>>
>>
>> I would like to present an RFC proposing support for native annotation.
>>
> Hi Dmitry,
>
> Although everyone will have an opinion about the syntax, I think there
> is one criticism that should be thought about; the chosen syntax isn't
> future expandable to other concerns.
>
> People have talked about "design by contract" RFCs where annotation
> like data is readable by the engine. The current proposed syntax
> _could_ be used to store DBC data, but it would not be clear what
> would be annotation data to read by the application, and what was DBC
> data to be read by the engine.
>
> Changing the proposed syntax to be something like @attr(...) would
> allow it to be expanded in the future by adding a @contract(...)
> construct:
>
> @attr(test($a + $b > 0))   // This is attribute data read by userland code
> @contract(require($a + $b > 0, 'InvalidFooArgsException'))  // This is
> DBC data read by the engine.
> function foo($a, $b) {
>      ...
> }
>
> Making features be compatible with future features would avoid a lot
> of potential pain down the road.
>
> cheers
> Dan
"@..." syntax can't work. @ - is a silence operator.

<<Contract\require($a + $b > 0, 'InvalidFooArgsException')>> - this is 
not really worse than your example.

I know, any syntax is going to be loved by ones and hated by others...
It's not possible to satisfy everyone.

Thanks. Dmitry.