On Wed, 2015-02-18 at 16:17 +0100, Nikita Popov wrote:
> On Wed, Feb 18, 2015 at 4:06 PM, Cesar Rodas <ce...@rodas.me> wrote:
>
> >
> > On 18/02/15 15:59, Nikita Popov wrote:
> > > On Wed, Feb 18, 2015 at 7:22 AM, Dmitry Stogov <dmi...@zend.com> wrote:
> > >
> > >> Hi,
> > >>
> > >> On Tue, Feb 17, 2015 at 2:46 PM, Alexander Lisachenko <
> > >> lisachenko...@gmail.com> wrote:
> > >>
> > >>> Hello, internals!
> > >>>
> > >>> I want to introduce a RFC for providing a userland API for accessing an
> > >>> Abstract Syntax Tree of the source code and to provide userland parser
> > >>> hooks for source code modification:
> > >>> https://wiki.php.net/rfc/parser-extension-api
> > >>>
> > >>> Thanks!
> > >>>
> > >> The first part, describing https://github.com/nikic/php-ast , looks
> > fine.
> > >> I see no problems including this extension into PHP-7.0 core
> > distribution.
> > >> May be even making it required (like ext/reflection).
> > >>
> > >> Nikita, what do you think?
> > >>
> > >> The second part looks very interesting, however it has some uncovered
> > >> questions.
> > >> - API for AST modification
> > >> - AST validation (someone may insert "break" node in "parameter-list").
> > >>
> > >> If you have enough experience, I would suggest you to try writing an
> > >> external extension that would implement this idea.
> > >> If you'll need some modification in PHP core (e.g adding callbacks), we
> > >> may consider including them in PHP-7.0.
> > >>
> > >> Thanks. Dmitry.
> > >>
> > > I agree with Dmitry.
> > >
> > > Exporting the AST to userland in PHP 7.0 would be nice. With Dmitry's
> > work
> > > on assertions we even have a pretty printer for it, which allows us to
> > > convert the AST back to PHP code.
> >
> > In this matter, how would it be? It'd be awesome if function expects an
> > AST tree object instead of a value:
> >
> > function doQuery($table, *$where) {
> > $where = convert_ast_toSqlWhere($where);
> > }
> >
> > doQuery("foobar", $col1 = "something" AND $col2 == $col3);
> >
> > Or at least `ast(<expr>)`, although both would be nice to have.
> >
>
> The problem here is that in most cases we do not actually know what
> function will be called at compile time. A very simple example would be to
> replace doQuery() with $db->query() and already we don't know what it is
> that we're actually calling and whether or not it needs an AST. However
> this does not apply to just methods, it's an issue with nearly all calls.
>
> As such PHP cannot know at compile time whether it should issue a normal
> call with evaluated arguments or whether it needs to preserve the AST and
> pass that. Just keeping the AST around for all calls would be too expensive
> (it's a pretty big memory hog).
>
> So rather than having this as a modifier in the function signature, it
> would have to be a modifier in the call syntax. E.g. rust uses foo!()
> syntax for macros.
>
> Nikita
Wouldn't the trick be to have $col1 be an object instance that uses
operator overloading? So instead of solving the expression, operators
would return the AST.
Was possible with the operator extension
Some old experimental code from 2006
echo query($connection,
array($catalog->Person->id, $catalog->Titles->title. ' ' .
$catalog->Person->name),
new SqlJoin(SqlJoin::TYPE_INNER,
$catalog->Person,
$catalog->Titles,
$catalog->Person->titleId == $catalog->Titles->id),
$catalog->Person->id == 1);
outputs
SELECT Person.id, Titles.title || ' ' || Person.name FROM Person INNER
JOIN Titles ON Person.titleId = Titles.id WHERE Person.id = 1
Jared
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
