Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92653
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 65.55.169.111 as permitted sender)
To: Thomas Punt <tpunt@hotmail.co.uk>, internals <internals@lists.php.net>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <DUB129-W57A238B87F13923C4AF1B9F96F0@phx.gbl>
Message-ID: <571B51CF.9040901@zend.com>
Date: Sat, 23 Apr 2016 13:43:27 +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: <DUB129-W57A238B87F13923C4AF1B9F96F0@phx.gbl>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2016 10:43:41.5898 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1781
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: dmitry@zend.com (Dmitry Stogov)



On 04/22/2016 02:46 PM, Thomas Punt wrote:
> Hi Dmitry!
>
>> Hi,
>>
>>
>> I would like to present an RFC proposing support for native annotation.
>>
>> The naming, syntax and behavior are mostly influenced by HHVM Hack, but not exactly the same.
>>
>> The most interesting difference is an ability to use arbitrary PHP expressions 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 "Design By Contract", other formal verification systems, Aspect Oriented Programming, 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 itself.
>>
>>
>> Additional ideas, endorsement and criticism are welcome.
> Just a couple of comments on this:
>
> 1. I'd definitely reuse the php-ast extension for parsing the code into an
> AST. It performs a number of transformations on PHP's underlying AST
> that make it much nicer to use (namely better consistency). It is also
> less fragile by having the abstraction between PHP's internal AST and
> the AST that is exposed to userland (enabling for internal AST changes
> without impacting the AST exposed to userland).
I'm not sure. Both approaches make sense.

>
> 2. You mentioned about moving some of the php-ast extension into core.
> I wonder if it would be better to just move the whole extension into the
> core first, and then enable this functionality if the php-ast extension is
> enabled.
Even if we move php-ast into core (I think we will do it), it's going to 
be optional.
However attributes should always work.

>
> Also, slightly tangential, but the RFC says attributes are supported on
> class constants, yet doc comments (IIRC) are not. I wonder if support
> for doc comments should be added for class constants?

it is already implemented.

Thanks. Dmitry.
>
> Thanks,
> Tom