Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83109
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-+zdywtuzVvpqxY_ZmrsAH++z5_kHMo9Lg1k_dJfYnMQ@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>
Date: Wed, 18 Feb 2015 23:30:21 +0400
Message-ID: <CAEbg-4auot0ZGdM5AbcLUS-dt_5cE-aag+nQrPv+GqT0ffG3ZQ@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=e89a8f643340a2f97b050f61d9d6
Subject: Re: [PHP-DEV] [RFC][Discussion] Parser extension API
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--e89a8f643340a2f97b050f61d9d6
Content-Type: text/plain; charset=UTF-8

> I'm okay with having stuff like ->getKindName() on the nodes, however I'd
> still keep around the free-standing functions, because they can be used
> without a node (i.e. you only need the kind AST_FOO and not an instantiated
> node).


I think that getting name of kind is useless without value of kind.
According to the RFC, there is only one way from user land to get a kind of
node: ask a parser for an AST, that will contain nodes. Is there any reason
to do getKindName(1), where 1 - is just integer value. I can't see how it
can be useful, this information is fully related to the node.

I also don't see why we need ParserEngine::parse() instead of just a
> (namespaced) parse() function. Not a fan of unnecessary wrapper classes.


I think that PHP is ugly enough :) We should try to use namespaces and
classes with methods to provide a better experience for user land
developers. Classes allow for logical composition of common functionality,
provides autocompletion in IDE and can be considered as step to
standardization of core API. (Today I discussed this question with
colleagues that will be great to have all system classes in Php namespace
for PHP>=7.0)

I know, that on engine level, classes aren't native, but you should think
about how this feature will be used by developers. Because, creation of API
is one-time process, but imagine how many times it will be used by
developers. I think, it will be more polite to provide OO-code for modern
API.

What's the advantage of this? Most leaf nodes will be zval nodes and I feel
> it would be rather inconvenient if they'd all have extra wrappers. Is there
> some specific problem with including the values directly?


Yes, reason here is the same as for `token_get_all()`. I hear so many WTFs
when value can be either simple character or array. Much harder to work
with inconsistent data and many libraries performs additional steps to
provide better usability (see
https://github.com/Andrewsville/PHP-Token-Reflection/blob/1c5ff91ee6877d1fb0f60fab3e3fc562bdb02684/TokenReflection/Stream/StreamBase.php#L100-L108
or
https://github.com/lisachenko/go-aop-php/blob/3c381e243367096d47dc9676b3ad7445d7720ba9/src/Instrument/Transformer/MagicConstantTransformer.php#L117
)

So, each element should be represented as common node, this will simplify
usage of API.

--e89a8f643340a2f97b050f61d9d6--