Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84229
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLvE8bFCdo=2ZJ6anMvHy+UhF-4C+_T_D7oQgkboHC-f=Q@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>
Date: Tue, 3 Mar 2015 14:56:40 +0300
Message-ID: <CAEbg-4Y0gzvSCPvboVR0UPv7V0RFLHSCeKdsgKDsjg01OAjpcA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Sara Golemon <pollita@php.net>, Nikita Popov <nikita.ppv@gmail.com>, Nikita Popov <nikic@php.net>, 
	PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c38d881fe17705106107ee
Subject: Re: [PHP-DEV] [RFC][Discussion] Parser extension API
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--001a11c38d881fe17705106107ee
Content-Type: text/plain; charset=UTF-8

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 <dmitry@zend.com>:

>
>
> On Thu, Feb 19, 2015 at 8:42 AM, Sara Golemon <pollita@php.net> wrote:
>
>> On Wed, Feb 18, 2015 at 11:22 AM, Dmitry Stogov <dmitry@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
>>
>
>

--001a11c38d881fe17705106107ee--