GRECLIPSE
  1. GRECLIPSE
  2. GRECLIPSE-1347

Argument names missing in method declaration when using code assist to implement missing methods

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.6.1.M1
    • Fix Version/s: 2.6.1.Release
    • Component/s: Editor
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Create a Groovy project and write the following interface:

      package test;
      
      public interface I
      {
      	void myMethod(String a, int b);
      }
      

      Then create a new Groovy class with the following contents:

      package test
      
      class A implements I {
        |	
      }
      

      Move the cursor to "|" and hit ctrl+space. Choose to override myMethod method in I. What I see is this:

      package test
      
      class A implements I {
      	void myMethod(String arg0, int arg1) {
      		// TODO Groovy Auto-generated method stub
      		// Only partially implemented. Perform organize imports
      		// to properly import parameter and return types
      	}
      }
      

      What I would expect is this:

      package test
      
      class A implements I {
      	void myMethod(String a, int b) {
      		// TODO Groovy Auto-generated method stub
      		// Only partially implemented. Perform organize imports
      		// to properly import parameter and return types
      	}
      }
      

        Activity

        Hide
        Andrew Eisenberg added a comment -

        It looks like if the super type is in the same file, then you do get the argument names, otherwise you get the broken ones.

        This may be a good time to try to fix the implementation of the method proposals.

        Show
        Andrew Eisenberg added a comment - It looks like if the super type is in the same file, then you do get the argument names, otherwise you get the broken ones. This may be a good time to try to fix the implementation of the method proposals.
        Hide
        Andrew Eisenberg added a comment -

        Wow. Turns out that with a little bit of tweaking, I can use JDT's OverrideMethodCompletionProposal. So, with this implemented, you will have exactly the same functionality in Groovy as you do with Java. However, it does not look like it will be easy to properly handle situations where the super type is parameterized.

        Show
        Andrew Eisenberg added a comment - Wow. Turns out that with a little bit of tweaking, I can use JDT's OverrideMethodCompletionProposal. So, with this implemented, you will have exactly the same functionality in Groovy as you do with Java. However, it does not look like it will be easy to properly handle situations where the super type is parameterized.
        Hide
        Andrew Eisenberg added a comment -

        Fixed the problem with generic super types. Also, comments and override annotations will be properly generated.

        Show
        Andrew Eisenberg added a comment - Fixed the problem with generic super types. Also, comments and override annotations will be properly generated.
        Hide
        Andrew Eisenberg added a comment -

        Return statements will have a semi-colon (since functionality is borrowed from Java), but I think that is acceptable.

        Show
        Andrew Eisenberg added a comment - Return statements will have a semi-colon (since functionality is borrowed from Java), but I think that is acceptable.
        Hide
        Andrew Eisenberg added a comment -

        Committed the fix for this.

        Show
        Andrew Eisenberg added a comment - Committed the fix for this.
        Hide
        Mauro Molinari added a comment -

        For me, the presence of the semicolons is absolutely acceptable. Maybe you can tweak it, if you wish, by applying a subsequent "quick fix" invocation to remove unneeded semicolons on the inserted code fragment immediately after?

        Show
        Mauro Molinari added a comment - For me, the presence of the semicolons is absolutely acceptable. Maybe you can tweak it, if you wish, by applying a subsequent "quick fix" invocation to remove unneeded semicolons on the inserted code fragment immediately after?
        Hide
        Andrew Eisenberg added a comment -

        Created GRECLSIPE-1353 to discuss ways of making the proposal application more groovy-like. Add more things to fix if you can think of anything.

        Show
        Andrew Eisenberg added a comment - Created GRECLSIPE-1353 to discuss ways of making the proposal application more groovy-like. Add more things to fix if you can think of anything.
        Hide
        Mauro Molinari added a comment -

        Hi Andrew,
        I'm using GRECLIPSE version 2.6.1.xx-20120301-1000-e37-RELEASE and I'm still seeing problems in this scenarios.

        The simple test case reported here works, even if there's the following secondary problem: if you put your cursor inside A class body and type my then invoke code assist, the code assist window says:

        myMethod(String arg0, int arg1): void - Override method in 'I'

        If you accept the proposal, public void myMethod(String a, int b) is correctly inserted, instead of public void myMethod(String arg0, int arg1).

        However there's a different scenario in which insertion is also wrong (i.e.: with missing argument names). Try this:

        package greclipse1347
        
        class B {
          void test() {
            I myvar = new I(){
              my|
            }
          }
        }
        

        Invoke code completion after my and accept the proposal of myMethod (by the way, it wasn't immediately visible to me, maybe I had to save the file for the proposal to show the first time... I don't know exactly). This is what is inserted for me:

        void myMethod(String arg0, int arg1) {};
        

        Not only argument names are missing, but there is the semicolon after the closing bracket and the code isn't formatted (i.e.: opening and closing brackets on the same line, no comments about auto generations, etc.).

        Another strange thing is that if you place the cursors inside new I()

        { ... }

        and you don't use contents assist at "my|" to implement the missing method, but you try to invoke right click -> Source -> Override/implement methods, it seems like it isn't recognized that I am inside the definition of an I instance, since the only methods I can select in the "Override/Implement methods" window are those of java.lang.Object.

        Show
        Mauro Molinari added a comment - Hi Andrew, I'm using GRECLIPSE version 2.6.1.xx-20120301-1000-e37-RELEASE and I'm still seeing problems in this scenarios. The simple test case reported here works, even if there's the following secondary problem: if you put your cursor inside A class body and type my then invoke code assist, the code assist window says: myMethod(String arg0, int arg1): void - Override method in 'I' If you accept the proposal, public void myMethod(String a, int b) is correctly inserted, instead of public void myMethod(String arg0, int arg1). However there's a different scenario in which insertion is also wrong (i.e.: with missing argument names). Try this: package greclipse1347 class B { void test() { I myvar = new I(){ my| } } } Invoke code completion after my and accept the proposal of myMethod (by the way, it wasn't immediately visible to me, maybe I had to save the file for the proposal to show the first time... I don't know exactly). This is what is inserted for me: void myMethod( String arg0, int arg1) {}; Not only argument names are missing, but there is the semicolon after the closing bracket and the code isn't formatted (i.e.: opening and closing brackets on the same line, no comments about auto generations, etc.). Another strange thing is that if you place the cursors inside new I() { ... } and you don't use contents assist at "my|" to implement the missing method, but you try to invoke right click -> Source -> Override/implement methods, it seems like it isn't recognized that I am inside the definition of an I instance, since the only methods I can select in the "Override/Implement methods" window are those of java.lang.Object.
        Hide
        Andrew Eisenberg added a comment -

        There's a lot that is not fully implemented with regards to inner/anonymous classes. This is not a problem with content assist, but with inner classes. Can you please raise a new bug for this with your comment above and it will specifically target inner/anonymous classes.

        Show
        Andrew Eisenberg added a comment - There's a lot that is not fully implemented with regards to inner/anonymous classes. This is not a problem with content assist, but with inner classes. Can you please raise a new bug for this with your comment above and it will specifically target inner/anonymous classes.
        Hide
        Mauro Molinari added a comment -

        I opened GRECLIPSE-1426, thank you.
        And what about the missing argument names in the code assist window, even in the case of this issue? Should I also open another ticket for that?

        Show
        Mauro Molinari added a comment - I opened GRECLIPSE-1426 , thank you. And what about the missing argument names in the code assist window, even in the case of this issue? Should I also open another ticket for that?
        Hide
        Mauro Molinari added a comment -

        I opened GRECLIPSE-1473 for the missing argument names in the code assist window.

        Show
        Mauro Molinari added a comment - I opened GRECLIPSE-1473 for the missing argument names in the code assist window.

          People

          • Assignee:
            Andrew Eisenberg
            Reporter:
            Mauro Molinari
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: