Community
Participate
Working Groups
20020402 I'm working on corrrection for unresolved field names: Assume this is the code: public void run(Runnable run) {} private void foo() { run(myRunnable); } myRunnable is not defined. Quick fix gives a proposal to introduce a new field. The problem is, what type has the field to introduce. If I resolve the MethodBinding of 'run' it is null, which makes sense, as 'myRunnable' is undefined, and run can't be 100% mapped. However, when hovering over run, codeSelect find out that this is run(Runnable) (as there is no other 'run' visible) Couldn't the AST also guess the method binding?
We have a special guessing mode for code selection. Unclear whether we would like to find a potential binding decoration in case message arguments could not be bound. For each unbound field/method, you would step to the parent level and guess its expected type for the unbound node ? But this would be tricky to generalize, since not only messages are involved here, but rather every compound expression...
I could try to do the guessing myself. How do I get the receiver type of my method?
I consider this feature as being beyond the scope of the DOM/AST API. The DOM/AST API is supposed to return bindings when they can be resolved. This is clearly not the case here.
The guessing technology was on SelectionOnMessageSend. We will experiment moving it into the base MessageSend node, only in error case. It is quite small, and if satisfactory then we will release it.
Fixed
