Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83082
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c8tSa640KrkzMk0kCE8x06m=y007u4zyB9_Zrh7vP3mJg@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>
Date: Wed, 18 Feb 2015 18:22:21 +0300
Message-ID: <CAEbg-4ZoLQ_MKPz4b9PoCuLj5rBYBOnSbnF4c2PG4odV=Vv=Rg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Dmitry Stogov <dmitry@zend.com>, Nikita Popov <nikic@php.net>, 
	PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bb03ea8c705eb050f5e62af
Subject: Re: [PHP-DEV] [RFC][Discussion] Parser extension API
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--047d7bb03ea8c705eb050f5e62af
Content-Type: text/plain; charset=UTF-8

2015-02-18 17:59 GMT+03:00 Nikita Popov <nikita.ppv@gmail.com>:

> Alexander, I would recommend you to split this into two RFCs, one dealing
> only with AST export (and maybe pretty printing) and the second one with
> the compilation hooks. There's probably a few questions about the export
> API that should be discussed that will be forgotten if everyone focuses on
> the more complicated, and probably not yet relevant, question of
> compilation hooks.



Hello, Nikita! Thanks for you thoughts!

Sounds reasonable for me, because of short timeframe for PHP7. Let's go
with the first part of RFC, because second part is really cumbersome and
can be applied later, eg. in 7.1 I will split this RFC into two parts and
mark first part for 7.0.

About first part, do you agree with proposed classes and namespace
`Php\Parser`? I want to propose to use classes for parser API instead of
pure functions because it can give more usable OO-API for future needs.

There is one more notice regarding to the zval nodes, they should be also
exported as objects, not as values. I think we should export coherent nodes
for everything.

--047d7bb03ea8c705eb050f5e62af--