Bug 164660

Summary: [API] Fup of bug 156352, ASTParser.createASTs(...) should be able to specify if all bindings must be completely resolved
Product: [Eclipse Project] JDT Reporter: Olivier Thomann <Olivier_Thomann>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: edwin, jerome_lanneluc, kent_johnson, markus.kell.r, martinae
Version: 3.3   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=150657
Whiteboard:

Description Olivier Thomann CLA 2006-11-15 11:28:35 EST
The user should be able to tell whether createASTs(...) should resolved all bindings (including the bindings for the units in the queue) or not.
Comment 1 Markus Keller CLA 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 CLA 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 CLA 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 CLA 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 CLA 2007-03-14 13:21:48 EDT
*** Bug 155399 has been marked as a duplicate of this bug. ***
Comment 6 Stephan Herrmann CLA 2019-11-16 12:05:19 EST
*** Bug 520000 has been marked as a duplicate of this bug. ***