Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92698
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.66 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CA+kxMuSxAWkNXai0kgW1b1anSohn63frjw76puo1PyCB=xWx=g@mail.gmail.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
	<CA+kxMuSxAWkNXai0kgW1b1anSohn63frjw76puo1PyCB=xWx=g@mail.gmail.com>
Date: Sun, 24 Apr 2016 10:57:58 -0600
Message-ID: <CAFMT4NrAshwagmGr6RcadbnLGoe71huA7yYcLYhW-Yf7ohFHGg@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: Dmitry Stogov <dmitry@zend.com>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: levim@php.net (Levi Morrison)

On Sun, Apr 24, 2016 at 10:03 AM, Dan Ackroyd <danack@basereality.com> 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.

Genuine question[1]: how is @attr() different than `<<attr()>>`? Also,
isn't `@attr()` 100% valid user-land code today that can precede
function or constant declarations?

  [1] I don't like that I have to make that explicit but it is what it is.