I think we must each have our own ideas of what this getNode<T> would do. I thought the idea was to search upward through the chain of parent builder links. For each builder, including the start one, we need to look through all the 'finished' matches stored in RecursiveBindings and Bindings. This implies some sort of traversal algorithm. This is what the iterator encapsulates. Putting this algorithm in getNode<T> won't make it any smaller.
The code could be reduced if all we cared about was the first node of matching Id and node type. In our discussions on 'combinatorial explosion', I thought we agreed this was preferable for usability. If so, that implies being able to get at matching nodes beyond the first and that's what the iterator is for. In the first round of reviews there was also a comment about co-locating searching code so we could easily swap it out for something else in the future. The iterator also serves this purpose. http://llvm-reviews.chandlerc.com/D788 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
