Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Outer references proposed before self references in Code Assist within 'with' closure #787

Closed
mauromol opened this issue Jan 7, 2019 · 6 comments
Assignees
Milestone

Comments

@mauromol
Copy link

mauromol commented Jan 7, 2019

Follow up of #364. Related to the discussion made on #674.

Consider this Groovy class:

package test45

class Test45 {
  static class Foo {
	  String someString = 'foo'
  }
  
  static class Bar {
	  String someString = 'bar'
	  Foo foo = new Foo()
	  
	  void doSomething() {
		  foo.with {
			  println "someString inside with closure = $someString"
			  println "someString of owner inside with closure = $owner.someString"
			  someS|
		  }
	  }
  }
  
  static main(args) {
	  Bar b = new Bar()
	  println "b.someString = $b.someString"
	  println "b.foo.someString = $b.foo.someString"
	  b.doSomething()
  }
}

Invoke code assist at "|": I would expect to see Foo.someString proposed before Bar.someString, because in this context (closure with delegation to self) it is reasonably the most natural choice.

@eric-milles
Copy link
Member

Are you looking for all proposals from delegate to come before owner proposals? Or just in the case of ties?

@eric-milles eric-milles self-assigned this Jan 7, 2019
@eric-milles eric-milles added this to the v3.3.0 milestone Jan 7, 2019
@mauromol
Copy link
Author

mauromol commented Jan 7, 2019

Hi Eric,
as already discussed in #674 IMHO the first criterion for sorting suggestion should not be the declaration scope, but rather a prediction of the user intent. For this reason I'm saying that exact matches should be shown first, followed by prefix matches, followed by substring matches, followed by camel case matches. In case of multiple options with the same relevance (what you call a "tie", I guess), then thinking about the scope is surely reasonable. In this case (probably in any similar case, when you're typing within a closure body?), I would say that the delegate proposals should be shown before the owner proposals, because, IMHO, in case of a tie they should be preferred (and this is confirmed by the fact that, in the above example, the delegate field is referenced by just someString, while the owner one by owner.someString, so in some way Groovy itself is giving precedence to the delegate).
So, in general, I would not say that ALL proposals from the delegate should come before ALL the owner proposals, but only when their relevance is the same with regards to the predicted user intent.

@eric-milles
Copy link
Member

Ready to test

@mauromol
Copy link
Author

mauromol commented Jan 8, 2019

Testing with 3.3.0.xx-201901072218-e49 I still see this:

immagine

@eric-milles
Copy link
Member

Ready for retest. I've tweaked the relevance multipliers so the prefix/camelCase/substring boosting has a little more effect for fields, methods and properties. It's not as you describe above, but should provide some separation in this case and static favorites should not intermix with local proposals.

@mauromol
Copy link
Author

mauromol commented Jan 9, 2019

I verified that 3.3.0.xx-201901082257-e49 works fine on this case, but not unfortunately on that of #674.
Thank you!

@mauromol mauromol closed this as completed Jan 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants