RE: [PHP-DEV] [RFC] PHP Attributes

From: Date: Sun, 24 Apr 2016 14:02:10 +0000
Subject: RE: [PHP-DEV] [RFC] PHP Attributes
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-92693@lists.php.net to get a copy of this message
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. >> 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. >> 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

« previous php.internals (#92693) next »