Bug 215331 - [assist] Inconsistent completions for member types
Summary: [assist] Inconsistent completions for member types
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4 M7   Edit
Assignee: David Audel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-15 06:43 EST by Philipe Mulet CLA
Modified: 2008-04-29 03:23 EDT (History)
2 users (show)

See Also:


Attachments
Proposed fix (41.83 KB, patch)
2008-04-07 05:02 EDT, David Audel CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philipe Mulet CLA 2008-01-15 06:43:25 EST
Build 3.4M4

The following 2 scenarii do not trigger similar proposals:

1. Map is not imported

   public class X {
	void foo() {
		Map.<CODEASSIST HERE>
	}
   }

   --> Offers 'Entry' with 'java.util.Map' as qualifier

2. Map is imported

   import java.util.Map;
   public class X {
	void foo() {
		Map.<CODEASSIST HERE>
	}
   }
 
   --> Offers 'Map<K,V>.Entry<K,V>' with 'java.util' qualifier

I find (2) inconsistent. (1) is more concise, and doesn't provide enclosing type as completion name (only as qualifier, which it really is).

Also, in (2) the proposed named suggests arguments for Map, which is irrelevant, since a raw type got entered (completion is behind the dot). Note that it only inserts a raw type in the end.
Comment 1 Philipe Mulet CLA 2008-01-15 07:09:24 EST
On presence of parameter types in proposals:

class A<T> {
  static class MemberStatic<U> {}
  class Member<V> {}
  void foo() {
	Member <CODEASSIST HERE> 
  }
}

I would expect following proposals:
   MemberStatic<U> - A
   Member<V> - A<T>

currently I get:
   A<T>.MemberStatic<U>
   A<T>.Member<V>
Comment 2 Philipe Mulet CLA 2008-01-15 07:10:59 EST
Small variation, when forcing raw enclosing type:

class A<T> {
  static class MemberStatic<U> {}
  class Member<V> {}

  void foo() {
	  A.Member<CODEASSIST HERE>
  }
}

I would expect following proposals:
   MemberStatic<U> - A
   Member - A

currently I get:
   A<T>.MemberStatic<U>
   A<T>.Member<V>
Comment 3 Philipe Mulet CLA 2008-01-15 07:13:59 EST
Yet another variation:

class A<T> {
  static class MemberStatic<U> {}
  class Member<V> {}

  void foo() {
	  A<T>.Member<CODEASSIST HERE>
  }
}

I would expect following proposals:
   Member<V> - A<T>
(only 1 proposal, since static member cannot be reached once enclosing got parameterized)

currently I get:
   A<T>.MemberStatic
   A<T>.Member
(note that currently, member types are no longer parameterized !?!?)
Comment 4 David Audel CLA 2008-04-07 05:02:06 EDT
Created attachment 95035 [details]
Proposed fix

- With this patch the following test case:

public class A<T> {
  static class MemberStatic<U> {}
  class Member<V> {}
  void foo() {
          A.Member<CODEASSIST HERE>
  }
}

will produce these proposals:

Member - A
MemberStatic<U> - A

- The following test case:

public class A<T> {
  static class MemberStatic<U> {}
  class Member<V> {}
  void foo() {
          A<Object>.Member<CODEASSIST HERE>
  }
}

will produce this proposal:

A<java.lang.Object>.Member<V>

- The following test case:

public class A<T> {
  static class MemberStatic<U> {}
  class Member<V> {}
  void foo() {
        Member <CODEASSIST HERE> 
  }
}

will produce these proposals:

A<T>.Member<V>
MemberStatic<U> - A
Comment 5 David Audel CLA 2008-04-07 05:52:02 EDT
Released for 3.4M7.

Tests added
  CompletionTests_1_5#test0339() -> test0350()
Comment 6 Eric Jodet CLA 2008-04-29 03:23:49 EDT
Verified for 3.4M7 using I20080427-2000.