> 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.