Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92667
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.195 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
Date: Sun, 24 Apr 2016 06:34:16 +0900
Message-ID: <CAGa2bXZdLL=DhZXjyFnAyUQO994+rcPKUp_rraQrsJxE3ookpg@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Dimitry,

On Fri, Apr 22, 2016 at 6:13 AM, Dmitry Stogov <dmitry@zend.com> wrote:
> I would like to present an RFC proposing support for native annotation.
>
> The naming, syntax and behavior are mostly influenced by HHVM Hack, but n=
ot exactly the same.
>
> The most interesting difference is an ability to use arbitrary PHP expres=
sions as attribute values.
>
> These expressions are not evaluated, but stored as Abstract Syntax Trees,=
 and later may be accessed (node by node) in PHP extensions, preprocessors =
and PHP scripts their selves. I think this ability may be useful for "Desig=
n By Contract", other formal verification systems, Aspect Oriented Programm=
ing, etc
>
>
> https://wiki.php.net/rfc/attributes
>
>
> Note that this approach is going to be native, in contrast to doc-comment=
 approach that uses not well defined syntax, and even not parsed by PHP its=
elf.
>
>
> Additional ideas, endorsement and criticism are welcome.

Nice RFC!
Attributes are always evaluated, right? i.e. No INI switch nor declare
to control behavior.
Just making sure.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net