Community
Participate
Working Groups
Eclipse 3.1 M7 It was very convinient in Eclipse that when it already knows type and I write "new " and press Ctrl+Space, it shows this type. For example: button.addActionListener(new {cursor}) But in M7 I have now look, what type should be used and write several first letters? Why? Please return old behaviour, at least make this optional.
I like it better the way it is now, as often I did not want to instantiate the declared type, but a subtype of it.
(In reply to comment #1) > I like it better the way it is now, as often I did not want to instantiate the > declared type, but a subtype of it. Thats right. Completion should offer list of subclasses too!
(In reply to comment #2) > (In reply to comment #1) > > I like it better the way it is now, as often I did not want to instantiate the > > declared type, but a subtype of it. > > Thats right. Completion should offer list of subclasses too! > But actually it offers nothing until you press a key. It should display the declared type and its known subtypes to choose from. After pressing a key, it should switch to the "new" behaviour.
(In reply to comment #1) > I like it better the way it is now, as often I did not want to instantiate the > declared type, but a subtype of it. I agree, that this can be often, may be for you in most cases you want subtype. But it was convinient and I always used this "auto-type" feature. Now I don't understand, why I should write any first letter, if Eclipse already knows type. Firstly, this is slower. When I enter first letter and press Ctrl+Space I see delay for about 300-400 ms. Old way was without any delay. Secondly, I already entered type one time, when I declare variable, in this case: ArrayList list = new {cursor} I don't want enter in second type... BTW, if you forced to enter first letter to repeat same type, it is better to use new "hippy completion" instead, because as I can see it always selects nearest word that starts with entered prefix, and because types always start with upper case it will not suggest variable name. Plus it works without any delay <g>.
(In reply to comment #4) > Secondly, I already entered type one time, when I declare variable +1 > ArrayList list = new {cursor} <pipsqueak> Small correction: for better code quality you should use the interface as the variable type: List list = new | </pipsqueak>
just a tip why not use new{CTLR-SPACE} That's even faster..
(In reply to comment #6) > just a tip > why not use > > new{CTLR-SPACE} > > That's even faster.. Not acceptable because you may need to use "new" inside method parameters. Also "New" template offer the same name for var and constructor, which does not work for collections and all other interface-based API.
(In reply to comment #4) > (In reply to comment #1) > > I like it better the way it is now, as often I did not want to instantiate the > > declared type, but a subtype of it. > > I agree, that this can be often, may be for you in most cases you want > subtype. But it was convinient and I always used this "auto-type" feature. Now I > don't understand, why I should write any first letter, if Eclipse already knows > type. > Firstly, this is slower. When I enter first letter and press Ctrl+Space I see > delay for about 300-400 ms. Old way was without any delay. > Secondly, I already entered type one time, when I declare variable, in this case: > ArrayList list = new {cursor} > I don't want enter in second type... > > BTW, if you forced to enter first letter to repeat same type, it is better to > use new "hippy completion" instead, because as I can see it always selects > nearest word that starts with entered prefix, and because types always start > with upper case it will not suggest variable name. Plus it works without any > delay <g>. I absolutely agree Konstantin. Francesc Rosés
(In reply to comment #2) > (In reply to comment #1) > > I like it better the way it is now, as often I did not want to instantiate the > > declared type, but a subtype of it. > > Thats right. Completion should offer list of subclasses too! > > Completion will not propose subclasses of an expected type because compute class hierarchy is currently too costly to compute and code assist would be too slow. So i see several possibilities 1) keep the current behavior: propose no types when completion token is empty 2) return the old behavior: propose expected and enclosing types when completion token is empty 3) propose expected types when completion token is empty and behind 'new' 4) keep the current behavior and add an option to enabled the behavior described in 2) or 3) What do you think about these possibilities (especially about 3) and 4)) ?
(In reply to comment #9) > Completion will not propose subclasses of an expected type because compute class > hierarchy is currently too costly to compute and code assist would be too slow. Yes. > > So i see several possibilities > 1) keep the current behavior: propose no types when completion token is empty > 2) return the old behavior: propose expected and enclosing types when completion > token is empty > 3) propose expected types when completion token is empty and behind 'new' > 4) keep the current behavior and add an option to enabled the behavior described > in 2) or 3) > > What do you think about these possibilities (especially about 3) and 4)) ? I like 3). I never understand why we need enclising types and never used this. If "expected" means "ArrayList" in case of "ArrayList list = new ", this is good. And really, when we already started enter some type prefix, this means that we want look on these types.
I never liked 2) because I usually use interfaces, and I would not like 3) for the same reason, although it would be slightly better. However, given the fact that the old way 'expected type' proposal seems to have many supporters, 4) may be the correct way to make it right for everyone...
> Completion will not propose subclasses of an expected type because compute class > hierarchy is currently too costly to compute and code assist would be too slow. That's sad, IDEA can complete subtypes without a performance problem.
(In reply to comment #5) > (In reply to comment #4) > > Secondly, I already entered type one time, when I declare variable > > +1 > > > ArrayList list = new {cursor} > > <pipsqueak> > Small correction: for better code quality you should use the interface as the > variable type: > > List list = new | > </pipsqueak> OK. We have, for example, something like this: List list = new | and we want List list = new ArrayList(); Now I must write: List list = new A<ctrl-space> and select form list or List list = new ArrayLi<ctrl-space> and select from list In previous releases I must write: List list = new ArrayL<ctrl-space> and select from list It seems the cost is similar... Now we have something like this: Integer integer = new | And we want Integer integer = new Integer In 3.1 M7 I must write Integer integer = new I<ctrl-space> because if I write Integer integer = new <ctrl-space> I don't obtains anything. In previous releases I must write Integet integer = new <ctrl-space> And I obtain Integer integer = new Integer with an extra Enter. And now... the conclusion: - First scenario (List list = new ArrayList()) More or less, the same programmer effort. 3.1 M7 points = 1 3.1 M6 points = 1 - Second scenario (Integer integer = new Integer()) The old behaviour requires less effort. 3.1 M7 points = 0 3.1 M6 points = 1 Total Points (first scenario points plus second scenario points): 3.1 M7 = 1 3.1 M6 = 2 Obviously the optimal solution is go back to the old behaviour. Francesc Rosés
(In reply to comment #13) > OK. We have, for example, something like this: > List list = new | > and we want > List list = new ArrayList(); > > Now I must write: > List list = new A<ctrl-space> and select form list or > List list = new ArrayLi<ctrl-space> and select from list > In previous releases I must write: > List list = new ArrayL<ctrl-space> and select from list > It seems the cost is similar... In IDEA you can write: List list = new | press Ctrl-Shift-Space and get a completion pop-up with List, all interfaces, that extend List, and all classes, that implement List. If you often use ArrayList, it is preselected, so you only have to press <Enter>.
Fixed and tests added CompletionTests#testCompletionExpectedTypeOnEmptyToken1() -> testCompletionExpectedTypeOnEmptyToken4() Inside a constructor name (after 'new'), if completion token is empty then expected type are proposed. ArrayList a = new | // ArrayList is proposed a = new | // variable type foo(new | // first parameter type is proposed Subtypes are currently not proposed (too costly) but that should be added post 3.1.
(In reply to comment #15) > Subtypes are currently not proposed (too costly) but that should be added post 3.1. 1:0 for IDEA :p
Build I20050527-0010. Works as specified in comment https://bugs.eclipse.org/bugs/show_bug.cgi?id=95505#c15. Discussed with David the case of interfaces (like 'List l = new |' which suggests List. The rationale is that the user may want to instanciate an anonymous class. While the List example may seem a bit odd, this is common practice for event listeners and other callbacks. I would contend that proposing type parameters is not optimal, hence I opened a separated bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=96944. This one should be considered as verified.
