Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76312
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <3F1B2834-3939-4F86-86E0-207D2CE469D6@ajf.me>
References: <CAF+90c-JHQ4MNLEDP6pZgw6YY37j2dzUK3k26cMWdpbXa1jRGA@mail.gmail.com>
	<3F1B2834-3939-4F86-86E0-207D2CE469D6@ajf.me>
Date: Sat, 2 Aug 2014 22:44:41 +0200
Message-ID: <CAF+90c-YUMUUQbcYxBPFPm1Q5eoX2=QOPrUMC=EVaxfO2QjKiA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0158aaa03ac01304ffab937d
Subject: Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree
From: nikita.ppv@gmail.com (Nikita Popov)

--089e0158aaa03ac01304ffab937d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 31, 2014 at 9:03 PM, Andrea Faulds <ajf@ajf.me> wrote:

> On another note, while we *could* allow extensions to hook into the AST,
> I=E2=80=99d stray away from letting them modify it and implement new feat=
ures. That
> really doesn=E2=80=99t sound like a good idea at all (I could elaborate o=
n why, but
> I won=E2=80=99t bother unless someone asks me).


Why do you think this isn't a good idea? I think it would be a nice way to
prototype language features before pulling them into PHP. Though admittedly
I don't think there are many things that could be implemented that way.


> Letting them read it would clearly be a good thing though. Side note:
> Would that obsolete your PHP-Parser userland library once an extension
> allows reading the AST? If an extension is written, perhaps it should hav=
e
> the same API as your library had. I believe many projects already use it.
>

A native extension has the limitation that it will not be able to parse
files for newer PHP versions (which, depending on the use case may or may
not be a problem) and probably won't provide a stable structure across
versions. At least I think giving BC guarantees on the AST structure
between minor versions would be way too limiting for us. As such I think
both a native ext (which provides awesome perf) and PHP-Parser (which
provides x-compat) have their place ;)


> On an *implementation* note, I assume this is based on the existing
> constant ASTs, unless you renamed it to something other then zend_ast. Do=
es
> this cause any problems for them? While I can see the benefits of course,
> I=E2=80=99d just like to be sure that the validator doesn=E2=80=99t let a=
nything slip
> through.
>

Yes, the AST structure is based on the existing work on constant scalar
expressions, though by now the structure and API deviate a good bit from
that. It doesn't cause problems for them - constant expressions go through
a validation that checks that only valid nodes are used and adjusts those
nodes that have special representation for the constexpr case (e.g.
constant and class constant access).

Nikita

--089e0158aaa03ac01304ffab937d--