Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92696
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.161.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
Date: Sun, 24 Apr 2016 17:03:07 +0100
Message-ID: <CA+kxMuSxAWkNXai0kgW1b1anSohn63frjw76puo1PyCB=xWx=g@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: danack@basereality.com (Dan Ackroyd)

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