Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84247
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEbg-4Y0gzvSCPvboVR0UPv7V0RFLHSCeKdsgKDsjg01OAjpcA@mail.gmail.com>
References: <CAEbg-4aZytKiqG3Y5U-HrBMp2+JuGHu3UTOMLWiiUQn59FtpLw@mail.gmail.com>
	<CA+9eiLvkoTB2xdo4a6AdDnU8fjxOBbog+4FHm-UyBZzWNOQd4Q@mail.gmail.com>
	<CAF+90c8tSa640KrkzMk0kCE8x06m=y007u4zyB9_Zrh7vP3mJg@mail.gmail.com>
	<CAEbg-4ZoLQ_MKPz4b9PoCuLj5rBYBOnSbnF4c2PG4odV=Vv=Rg@mail.gmail.com>
	<CAF+90c-+zdywtuzVvpqxY_ZmrsAH++z5_kHMo9Lg1k_dJfYnMQ@mail.gmail.com>
	<CA+9eiLvVySGcxaB5q4a-tyUaKQE5wnv+asJni+s++BZXO5u+pg@mail.gmail.com>
	<CAESVnVq-JeioKBLwVFx+Ozx1HegtyH6241rgweMh+68yZZoX+w@mail.gmail.com>
	<CA+9eiLvE8bFCdo=2ZJ6anMvHy+UhF-4C+_T_D7oQgkboHC-f=Q@mail.gmail.com>
	<CAEbg-4Y0gzvSCPvboVR0UPv7V0RFLHSCeKdsgKDsjg01OAjpcA@mail.gmail.com>
Date: Tue, 3 Mar 2015 16:12:25 +0000
Message-ID: <CAPwsocGBLBzBwVeB_xS04jPMyueqbBhR_B7ud=11pNFO6d6+Eg@mail.gmail.com>
To: Alexander Lisachenko <lisachenko.it@gmail.com>
Cc: Sara Golemon <pollita@php.net>, Nikita Popov <nikic@php.net>, 
	PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][Discussion] Parser extension API
From: leight@gmail.com (Leigh)

On 3 March 2015 at 11:56, Alexander Lisachenko <lisachenko.it@gmail.com> wrote:
> 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

+1

> 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 had no idea that zend_ast_process was such a recent addition, and
part of your proposal. I've actually started using it already
completely independently in one of my extensions!

> 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)

I think we need to at least represent all of the current node structures.

A common base class, and then classes to represent lists, zvals and
decls that extend from this base.

> 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)

Thinking for the future is fine, but do we need this metadata for the
current proposal? Is the AST returned by the parser in a read-only
state, or can users create their own nodes + children and get a pretty
printed output? If it's the latter then we obviously need to know the
restrictions.

I think we need a mechanism that keeps names/numbers in sync
automatically, maybe we can use some macros to automatically generate
enums and userland facing details at the same time, so we don't have
to keep several places in sync if/when new AST nodes are added.