Good morning! I have cleaned https://wiki.php.net/rfc/parser-extension-api and restricted it's scope only to the parsing API. Extension API can be implemented later on top of https://github.com/php/php-src/commit/1010b0ea4f4b9f96ae744f04c1191ac228580e48 and current implementation, because it requires a lot of discussion and can not be implemented right now.
I want to move this RFC to the vote phase soon to decide if it will be included into PHP7.0 or not. So let's discuss open questions before moving it to the vote phase (from SO chat) 1. Should each node type be represented as personal class? There are two possible ways: single node class for everything (current proposal) and separate class for every node kind. I have made a quick research of AST API in several languages and noticed, that most of them generates AST class nodes automatically. E.g. UnaryOperationNode, StatementNode... This way is cool, but it requires a lot of classes to be loaded and available as API. Pros: SRP of each node class, AST validators (can be described with XML and DTD), more clear code analysis (checks with $node instaceof StatementNode), typehints for concrete nodes for visitors. However, PHP is dynamic language and we can use only one class for everything, adjusting `kind` property for each node. Pros: single class, easier to maintain and to use. Cons: bad UX (how to validate nodes, how to determine number of available children, how to check is node using flags or not, etc) 2. Where metadata should be stored (flags, names of kind nodes, relation between node types)? This information will be needed later for validation of AST Nikita have some thoughts for the future :) So he asked about the storage of metadata to validate an AST and to perform some analysis on it. Metadata should include the following: name of each node kind (this can be just a class name of node or constants in the class), node restrictions (which kind of node types can be used as children for concrete node; number of children nodes), node flag names (it's PUBLIC, PROTECTED, PRIVATE, etc) 2015-02-19 10:22 GMT+03:00 Dmitry Stogov <dmi...@zend.com>: > > > On Thu, Feb 19, 2015 at 8:42 AM, Sara Golemon <poll...@php.net> wrote: > >> On Wed, Feb 18, 2015 at 11:22 AM, Dmitry Stogov <dmi...@zend.com> wrote: >> > I think the AST API shouldn't use "public" properties. >> > Using it, we will have to construct the whole tree of objects, >> duplicating >> > information from AST. >> > I would propose SimpleXML approach instead - construct object only for >> > node(s) we currently access. >> > >> > So at first we will construct just single object referring to AST root. >> > Then traversing it we will create and destroy objects for necessary >> nodes. >> > >> I'm not sure if you've seen my astkit extension, but it does this. >> >> https://github.com/sgolemon/astkit >> > > I didn't see it before, and took just a quick look, but I like it. > Any special reason, why you didn't implement ArrayAccess interface for > children access? > For me it would look natural. > > Thanks. Dmitry. > > >> >> -Sara >> > >
