Community
Participate
Working Groups
2.x Now that we have AST rewriting we more and more start to modify existing ASTs. After the first modification all bindings associated with nodes are null. Since we want to walk the tree and modifiy it in parallel clients should be able to create an AST that keeps bindings even if the AST gets modified. New nodes simply don't return bindings.
Jim - any comment? We added this considering that bindings are irrelevant as soon as the tree is modified.
The original thinking was that we might want to compute IBindings lazily, and once the client starts editing the AST they would be no obvious way to do this. As it turned out, we compute all IBindings eagerly, so this is no longer an issue. Keeping some binding info once modification begins should be possible (but keeping all binding info is likely too costly). The challenge is coming up with a story that is easy for clients to work with, and can be implemented without too much additional cost. It would be helpful to have usecases of where client would reasonably expect bindings to be preserved. Example: how important is it to be able to add/delete a statement in a block without disrupting its siblings?
Why is keeping all binding infos to costly given the fact that we compute them eagerly anyway ? One example is that we want to exchange one type with another type in a CU. In this call Type bindings should be kept.
I'd vote to leave the bindings in, with a disclaimer indicating that a change is a non-returning point from where bindings may be stale.
Changed spec (for AST.parseCompilationUnit) to say that all bindings are computed at the time the AST is created. If you modify the AST, you get exactly the same bindings as you would have gotten had you not modified the AST.
First version released in 2.1 stream. Regression test added (test0409).
Verified.
