Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92712
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 157.56.111.104 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> <571B51CF.9040901@zend.com>
 <DUB129-W785F4CB7CFFA17BFEC2C4DF9610@phx.gbl>
Message-ID: <571DD397.9090007@zend.com>
Date: Mon, 25 Apr 2016 11:21:43 +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-W785F4CB7CFFA17BFEC2C4DF9610@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: 25 Apr 2016 08:21:58.4576 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0201MB1779
Subject: Re: [PHP-DEV] [RFC] PHP Attributes
From: dmitry@zend.com (Dmitry Stogov)



On 04/24/2016 05:02 PM, Thomas Punt wrote:
> Hi!
>
>> From: dmitry@zend.com
>>> On 04/22/2016 02:46 PM, Thomas Punt wrote:
>>> Hi Dmitry!
>>>
>>> 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.
> Whilst fragility is a concern, a bigger problem with not reusing
> ast\parse_code() is that the AST produced will be different in even the
> simplest of cases. For example, take the following simple expression:
>
> $a> 2
>
> With your attributes branch, this will produce an AST of:
>
> object(ast\Node)#2 (4) {
>      ["kind"]=> int(521) // ZEND_AST_GREATER
>      ["flags"]=> int(0)
>      ["lineno"]=> int(1)
>      ["children"]=> [...]
> }
>
> Whereas with ast\parse_code(), the following AST will be produced:
>
> object(ast\Node)#2 (4) {
>      ["kind"]=> int(520) // AST_BINARY_OP
>      ["flags"]=> int(256) // BINARY_IS_GREATER
>      ["lineno"]=> int(1)
>      ["children"]=> [...]
> }
>
> The php-ast extension transforms the special node types for>,>=, <, <=
> into AST_BINARY_OP nodes with different flags set. This is just one
> difference of many between the internal AST and the AST produced by
> the php-ast extension.

This is initial implementation details, and they are going to be fixed.
If we decide to use AST in attributes, getAttributes() outout are going 
to be 100% compatible with php-ast.

>
>>> 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.
> If we're going to reuse ast\parse_code(), then we will need the whole php-ast
> extension in the core. It could therefore be made similar to the pcre, date,
> Reflection, SPL, etc extensions, where it cannot be disabled.

Right,  but this is out of scope of this RFC.
Nikita was going to propose moving php-ast into core soon.

Thanks. Dmitry.

>
>>> 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.
> Oh right, my mistake. It does not seem to be exposed through php-ast or
> reflection then.
>
>> Thanks. Dmitry.
>>> Thanks,
>>> Tom
> -Tom