<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 21, 2012, at 9:43 AM, Ben Gertzfield <<a href="mailto:bgertzfield@gmail.com">bgertzfield@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Thu, Dec 20, 2012 at 10:28 PM, Dmitri Gribenko <span dir="ltr"><<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>></span> wrote:<div><br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">So certainly, workarounds are possible, and we can somehow maintain<br></div>
the old API *and* keep binary compatibility. But is it worth it? It<br>
depends on how useful it is.</blockquote><div><br></div><div style="">The XML "API" is flexible because of its simplicity: it returns a string containing a serialized tree of nodes, each of which has:<br><br></div>
<div style="">1) A name (== type)</div><div style="">2) Zero or more key-value parameter pairs</div><div style="">3) Zero or more children (which can be either nodes or text)</div><div style=""><br></div><div style="">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.</div>
</div></div></div></div></blockquote><br></div><div>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.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><br></body></html>