Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92693
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.co.uk designates 157.55.0.205 as permitted sender)
Message-ID: <DUB129-W785F4CB7CFFA17BFEC2C4DF9610@phx.gbl>
To: Dmitry Stogov <dmitry@zend.com>, internals <internals@lists.php.net>
Date: Sun, 24 Apr 2016 15:02:10 +0100
Importance: Normal
In-Reply-To: <571B51CF.9040901@zend.com>
References:
 <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>,<DUB129-W57A238B87F13923C4AF1B9F96F0@phx.gbl>,<571B51CF.9040901@zend.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [RFC] PHP Attributes
From: tpunt@hotmail.co.uk (Thomas Punt)

Hi!=0A=
=0A=
> From: dmitry@zend.com=0A=
>> On 04/22/2016 02:46 PM=2C Thomas Punt wrote:=0A=
>> Hi Dmitry!=0A=
>>=0A=
>> Just a couple of comments on this:=0A=
>>=0A=
>> 1. I'd definitely reuse the php-ast extension for parsing the code into =
an=0A=
>> AST. It performs a number of transformations on PHP's underlying AST=0A=
>> that make it much nicer to use (namely better consistency). It is also=
=0A=
>> less fragile by having the abstraction between PHP's internal AST and=0A=
>> the AST that is exposed to userland (enabling for internal AST changes=
=0A=
>> without impacting the AST exposed to userland).=0A=
>=0A=
> I'm not sure. Both approaches make sense.=0A=
=0A=
Whilst fragility is a concern=2C a bigger problem with not reusing=0A=
ast\parse_code() is that the AST produced will be different in even the=0A=
simplest of cases. For example=2C take the following simple expression:=0A=
=0A=
$a> 2=0A=
=0A=
With your attributes branch=2C this will produce an AST of:=0A=
=0A=
object(ast\Node)#2 (4) {=0A=
=A0 =A0 ["kind"]=3D>=A0int(521) // ZEND_AST_GREATER=0A=
=A0 =A0 ["flags"]=3D>=A0int(0)=0A=
=A0 =A0 ["lineno"]=3D>=A0int(1)=0A=
=A0 =A0=A0["children"]=3D> [...]=0A=
}=0A=
=0A=
Whereas with ast\parse_code()=2C the following AST will be produced:=0A=
=0A=
object(ast\Node)#2 (4) {=0A=
=A0=A0=A0 ["kind"]=3D>=A0int(520) // AST_BINARY_OP=0A=
=A0 =A0 ["flags"]=3D>=A0int(256) // BINARY_IS_GREATER=0A=
=A0 =A0 ["lineno"]=3D>=A0int(1)=0A=
=A0 =A0 ["children"]=3D> [...]=0A=
}=0A=
=0A=
The php-ast extension transforms the special node types for>=2C>=3D=2C <=2C=
 <=3D=0A=
into AST_BINARY_OP nodes with different flags set. This is just one=0A=
difference of many between the internal AST and the AST produced by=0A=
the php-ast extension.=0A=
=0A=
>> 2. You mentioned about moving some of the php-ast extension into core.=
=0A=
>> I wonder if it would be better to just move the whole extension into the=
=0A=
>> core first=2C and then enable this functionality if the php-ast extensio=
n is=0A=
>> enabled.=0A=
>=0A=
> Even if we move php-ast into core (I think we will do it)=2C it's going t=
o=0A=
> be optional.=0A=
> However attributes should always work.=0A=
=0A=
If we're going to reuse ast\parse_code()=2C then we will need the whole php=
-ast=0A=
extension in the core. It could therefore be made similar to the pcre=2C da=
te=2C=0A=
Reflection=2C SPL=2C etc=A0extensions=2C where it=A0cannot be disabled.=0A=
=0A=
>> Also=2C slightly tangential=2C but the RFC says attributes are supported=
 on=0A=
>> class constants=2C yet doc comments (IIRC) are not. I wonder if support=
=0A=
>> for doc comments should be added for class constants?=0A=
>=0A=
> it is already implemented.=0A=
=0A=
Oh right=2C my mistake. It does not seem to be exposed through php-ast or=
=0A=
reflection then.=0A=
=0A=
> Thanks. Dmitry.=0A=
>>=0A=
>> Thanks=2C=0A=
>> Tom=0A=
=0A=
-Tom 		 	   		  =