[cfe-commits] [PATCH] Add Python bindings to comment AST introspection APIs

Douglas Gregor dgregor at apple.com
Fri Dec 21 09:55:27 PST 2012


On Dec 21, 2012, at 9:43 AM, Ben Gertzfield <bgertzfield at gmail.com> wrote:

> On Thu, Dec 20, 2012 at 10:28 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> 
> So certainly, workarounds are possible, and we can somehow maintain
> the old API *and* keep binary compatibility.  But is it worth it?  It
> depends on how useful it is.
> 
> The XML "API" is flexible because of its simplicity: it returns a string containing a serialized tree of nodes, each of which has:
> 
> 1) A name (== type)
> 2) Zero or more key-value parameter pairs
> 3) Zero or more children (which can be either nodes or text)
> 
> Perhaps we can simplify the C AST API to return an iterator over such a tree? Then it's infinitely flexible, just like the XML "API". We can add types, remove types, add parameters, remove parameters, etc. at any time, maintaining binary compatibility.

What you're describing isn't all that different in design from the CXCursor interface in libclang. Yes, it's flexible. Yes, we've been able to maintain binary compatibility for a long time. However, the downside is that the interface is so open and so flexible that users use it very, very poorly. They get all of the default cases wrong, so when we change something (add a new AST node, etc.), we get weird behavior. Users have done far better with the "bulk" interfaces libclang provides, which is why we've been moving in that direction for libclang. Plus, it's better for the grand future, where we hope to have a Clang service to implement these bulk interfaces.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121221/2d6956a0/attachment.html>


More information about the cfe-commits mailing list