Comment 1 Markus Keller 2006-11-15 12:02:26 EST

I was not aware of the semantic shift of the fix for bug 114935, but in the end, I think the original ASTParser.createASTs(..) method should be deprecated, since it really changed in an incompatible way between 3.1 and 3.2.

If bug 150657 is implemented, then I guess we wouldn't need this special API.

Comment 2 Olivier Thomann 2006-11-16 10:56:53 EST

Could we add a method in org.eclipse.jdt.core.dom.ASTRequestor that would be used to know if the units in the queue need to be cleaned?
Something like:
public boolean resolveAllUnitsInQueue() {
    return false;
}
By default this would return false to preserve actual behavior.

This would not be a breaking change unless this method has been defined by subclasses of org.eclipse.jdt.core.dom.ASTRequestor.

Comment 3 Olivier Thomann 2006-11-16 11:00:37 EST

or:
public boolean cleanAllUnitsInQueue() {
    return false;
}

since we don't actually resolve them, but simply leave their scopes around for further resolution like in createAST(...).

Comment 4 Markus Keller 2006-11-16 14:10:04 EST

Yes, that's what I proposed in bug 156352 comment 18. But we have to find a good name for the API, since *AllUnitsInQueue() is too implementation-centric and does not tell about the consequences (which is the only thing the client cares about).

How about one of:
- leaveBindingsIncomplete() { return false; }
- stopResolvingBindings() { return false; }
- fullyResolveBindings() { return true; }
... of course completed with javadoc which tells about the memory and performance impact, and that bindings are always complete as long as you're in an accept*(..) callback, but may not be complete if queried after createASTs(..).

One point I don't really like about the overridable method is that it could change the returned value over time. Maybe it would be clearer it the flag would be added as ASTParser#createASTs(.., boolean fullyResolveBindings) or as a new constructor ASTRequestor(boolean fullyResolveBindings).

Comment 5 Olivier Thomann 2007-03-14 13:21:48 EDT

*** Bug 155399 has been marked as a duplicate of this bug. ***

Comment 6 Stephan Herrmann 2019-11-16 12:05:19 EST

*** Bug 520000 has been marked as a duplicate of this bug. ***