OComplection
Locked
 
|
the more time I spend with OCompletion the more I think it's the wrong model:
NECompletion provides in many cases way better / quicker results NOCompletion does tons of magic to increase the chances of a correct hit, neglecting - self sends - super sends - ClassSends which is basically the main source for getting nice input... I think NOCompletion should be removed. The only thing that might maintain is a Database which will give back a date for a given selector so we can sort them accordingly. But IMO that can be solved muuuuch easier. Things against NOCompletion: - not documentation whatsoever (no class comments no comments no categories... nada) - totally breaks type completion (self sends usw...) - duplication of NECompletion... Since I don't see anybody maintaining this dead body we should remove it from the system! |
|
|
> the more time I spend with OCompletion the more I think it's the wrong model: > > NECompletion provides in many cases way better / quicker results > > NOCompletion does tons of magic to increase the chances of a correct hit, > neglecting > - self sends > - super sends > - ClassSends > > which is basically the main source for getting nice input... > > I think NOCompletion should be removed. The only thing that might maintain > is a Database which will give back a date for a given selector so we can > sort them accordingly. But IMO that can be solved muuuuch easier. > > > Things against NOCompletion: > - not documentation whatsoever (no class comments no comments no categories... nada) > - totally breaks type completion (self sends usw...) > - duplication of NECompletion... > > Since I don't see anybody maintaining this dead body we should remove it > from the system! Why not but do we get the most recently typed because this is cool to have Stef |
|
|
In reply to this post by Camillo Bruni-3
OCompletion works fine for me. And is much more valuable for me than EC... yes we can (and need) improve it, but I don't want to drop OC.
Is the same case of nautilus many-methods and tabs. Just because you don't find the function valuable, that does not means that it is not worthy for anybody :) Esteban On Aug 6, 2012, at 12:15 AM, Camillo Bruni <[hidden email]> wrote: > the more time I spend with OCompletion the more I think it's the wrong model: > > NECompletion provides in many cases way better / quicker results > > NOCompletion does tons of magic to increase the chances of a correct hit, > neglecting > - self sends > - super sends > - ClassSends > > which is basically the main source for getting nice input... > > I think NOCompletion should be removed. The only thing that might maintain > is a Database which will give back a date for a given selector so we can > sort them accordingly. But IMO that can be solved muuuuch easier. > > > Things against NOCompletion: > - not documentation whatsoever (no class comments no comments no categories... nada) > - totally breaks type completion (self sends usw...) > - duplication of NECompletion... > > Since I don't see anybody maintaining this dead body we should remove it > from the system! |
|
|
Maybe I don't really see when it gets useful...
Can you give me an example where you rely on the history information of OCompletion? On 2012-08-06, at 12:34, Esteban Lorenzano <[hidden email]> wrote: > OCompletion works fine for me. And is much more valuable for me than EC... yes we can (and need) improve it, but I don't want to drop OC. > Is the same case of nautilus many-methods and tabs. Just because you don't find the function valuable, that does not means that it is not worthy for anybody :) > > Esteban > > On Aug 6, 2012, at 12:15 AM, Camillo Bruni <[hidden email]> wrote: > >> the more time I spend with OCompletion the more I think it's the wrong model: >> >> NECompletion provides in many cases way better / quicker results >> >> NOCompletion does tons of magic to increase the chances of a correct hit, >> neglecting >> - self sends >> - super sends >> - ClassSends >> >> which is basically the main source for getting nice input... >> >> I think NOCompletion should be removed. The only thing that might maintain >> is a Database which will give back a date for a given selector so we can >> sort them accordingly. But IMO that can be solved muuuuch easier. >> >> >> Things against NOCompletion: >> - not documentation whatsoever (no class comments no comments no categories... nada) >> - totally breaks type completion (self sends usw...) >> - duplication of NECompletion... >> >> Since I don't see anybody maintaining this dead body we should remove it >> from the system! > > |
|
|
well... I cannot. But for me, most of the time OCompletion suggestions are accurate (because I tend to use always the same methods, probably).
btw, I'm not saying that OCompletion is perfect, I think it can be improved a lot... but I like it (what you did is already better, but it can be improved more) On Aug 6, 2012, at 1:02 PM, Camillo Bruni <[hidden email]> wrote: > Maybe I don't really see when it gets useful... > Can you give me an example where you rely on the history information of OCompletion? > > > On 2012-08-06, at 12:34, Esteban Lorenzano <[hidden email]> wrote: >> OCompletion works fine for me. And is much more valuable for me than EC... yes we can (and need) improve it, but I don't want to drop OC. >> Is the same case of nautilus many-methods and tabs. Just because you don't find the function valuable, that does not means that it is not worthy for anybody :) >> >> Esteban >> >> On Aug 6, 2012, at 12:15 AM, Camillo Bruni <[hidden email]> wrote: >> >>> the more time I spend with OCompletion the more I think it's the wrong model: >>> >>> NECompletion provides in many cases way better / quicker results >>> >>> NOCompletion does tons of magic to increase the chances of a correct hit, >>> neglecting >>> - self sends >>> - super sends >>> - ClassSends >>> >>> which is basically the main source for getting nice input... >>> >>> I think NOCompletion should be removed. The only thing that might maintain >>> is a Database which will give back a date for a given selector so we can >>> sort them accordingly. But IMO that can be solved muuuuch easier. >>> >>> >>> Things against NOCompletion: >>> - not documentation whatsoever (no class comments no comments no categories... nada) >>> - totally breaks type completion (self sends usw...) >>> - duplication of NECompletion... >>> >>> Since I don't see anybody maintaining this dead body we should remove it >>> from the system! >> >> > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |