Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76495
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F310104A-1E82-4E64-8C23-42E9BAE51BA2@ajf.me>
References: <CAF+90c-JHQ4MNLEDP6pZgw6YY37j2dzUK3k26cMWdpbXa1jRGA@mail.gmail.com>
 <3F1B2834-3939-4F86-86E0-207D2CE469D6@ajf.me> <CAF+90c-YUMUUQbcYxBPFPm1Q5eoX2=QOPrUMC=EVaxfO2QjKiA@mail.gmail.com>
 <F310104A-1E82-4E64-8C23-42E9BAE51BA2@ajf.me>
Date: Wed, 13 Aug 2014 13:18:31 -0400
Message-ID: <CAFp73XsC2naCKq3MFMNURk3HuMw3xtV_bAmoBRpEykC6gb=-Qg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0111d7585fad82050085fb16
Subject: Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--089e0111d7585fad82050085fb16
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

When is this planned to go through voting process?


On Sat, Aug 2, 2014 at 5:27 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi!
>
> On 2 Aug 2014, at 21:44, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> > 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.
>
> If people can extend the syntax, they will, and I don=E2=80=99t like the =
possible
> consequences of that. I=E2=80=99m all for overloading, but if people star=
t relying
> on custom syntactical features, it means non-portable and confusing to re=
ad
> code. Granted, it might be useful for prototyping, but prototyping itself
> would be easier with an AST, so I=E2=80=99m not sure it matters.
>
> > 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 ;)
>
> Yeah, I was thinking that you could keep it around for version
> compatibility. You could even make your library pass through to the nativ=
e
> ext where possible. :)
>
> > 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 throug=
h
> 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)
>
> Ah, I see.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--=20
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--089e0111d7585fad82050085fb16--