www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Poll: show op* or not in autocompletion?

reply Ary Borenszweig <ary esperanto.org.ar> writes:
Hi,

I'm improving Descent's autocompletion proposals, and I was wondering 
whether to show or hide methods such as opCmp, opEquals, opCall, etc.

What do you think, should an IDE show these or not?
Apr 13 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Ary Borenszweig wrote:
 Hi,
 
 I'm improving Descent's autocompletion proposals, and I was wondering 
 whether to show or hide methods such as opCmp, opEquals, opCall, etc.
 
 What do you think, should an IDE show these or not?

Can it show them only after someone types ".op" ? --bb
Apr 13 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Bill Baxter escribió:
 Ary Borenszweig wrote:
 Hi,

 I'm improving Descent's autocompletion proposals, and I was wondering 
 whether to show or hide methods such as opCmp, opEquals, opCall, etc.

 What do you think, should an IDE show these or not?

Can it show them only after someone types ".op" ? --bb

That's a good idea. What I'm looking for is some way to hide these methods, because you'd never want to write foo.opCmp(...) but you might just want to know which op* are defined for a given class. So your suggestion might be a solution. Thanks. :-)
Apr 13 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig escribió:
 Bill Baxter escribió:
 Ary Borenszweig wrote:
 Hi,

 I'm improving Descent's autocompletion proposals, and I was wondering 
 whether to show or hide methods such as opCmp, opEquals, opCall, etc.

 What do you think, should an IDE show these or not?

Can it show them only after someone types ".op" ? --bb

That's a good idea. What I'm looking for is some way to hide these methods, because you'd never want to write foo.opCmp(...) but you might just want to know which op* are defined for a given class. So your suggestion might be a solution. Thanks. :-)

Another way might be to show the op* methods, and when you accept them, they turn into the corresponding symbol, like foo.opCmp(o) --> foo == o foo.opAdd(o) --> foo + o But I guess no one will find use in that.
Apr 13 2008
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 13 Apr 2008 23:16:48 +0200, Ary Borenszweig <ary esperanto.org.a=
r>  =

wrote:

 Ary Borenszweig escribi=F3:
 Bill Baxter escribi=F3:
 Ary Borenszweig wrote:
 Hi,

 I'm improving Descent's autocompletion proposals, and I was wonderi=




 whether to show or hide methods such as opCmp, opEquals, opCall, et=




 What do you think, should an IDE show these or not?

Can it show them only after someone types ".op" ? --bb

What I'm looking for is some way to hide these methods, because you'=


 never want to write
  foo.opCmp(...)
  but you might just want to know which op* are defined for a given  =


 class. So your suggestion might be a solution. Thanks. :-)

Another way might be to show the op* methods, and when you accept them=

 they turn into the corresponding symbol, like

 foo.opCmp(o) --> foo =3D=3D o
 foo.opAdd(o) --> foo + o

 But I guess no one will find use in that.

And why not both? Hide them at first, show them if you start writing ".op", and if you accept them, replace with correct symbol. -- Simen
Apr 13 2008
prev sibling next sibling parent reply Hendrik Renken <funsheep gmx.net> writes:
Ary Borenszweig wrote:
 Ary Borenszweig escribió:
 Bill Baxter escribió:
 Ary Borenszweig wrote:
 Hi,

 I'm improving Descent's autocompletion proposals, and I was 
 wondering whether to show or hide methods such as opCmp, opEquals, 
 opCall, etc.

 What do you think, should an IDE show these or not?

Can it show them only after someone types ".op" ? --bb

That's a good idea. What I'm looking for is some way to hide these methods, because you'd never want to write foo.opCmp(...) but you might just want to know which op* are defined for a given class. So your suggestion might be a solution. Thanks. :-)

Another way might be to show the op* methods, and when you accept them, they turn into the corresponding symbol, like foo.opCmp(o) --> foo == o foo.opAdd(o) --> foo + o But I guess no one will find use in that.

i would! In fact this was my first thought when i read your post. i find this intuitive. As i work often work with eclipse, why not improve the content assistant when you press again strg+space (or what ever), instead of the template proposals, show the .op* symbols.
Apr 17 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Hendrik Renken wrote:
 Ary Borenszweig wrote:
 Ary Borenszweig escribió:
 Bill Baxter escribió:
 Ary Borenszweig wrote:
 Hi,

 I'm improving Descent's autocompletion proposals, and I was 
 wondering whether to show or hide methods such as opCmp, opEquals, 
 opCall, etc.

 What do you think, should an IDE show these or not?

Can it show them only after someone types ".op" ? --bb

That's a good idea. What I'm looking for is some way to hide these methods, because you'd never want to write foo.opCmp(...) but you might just want to know which op* are defined for a given class. So your suggestion might be a solution. Thanks. :-)

Another way might be to show the op* methods, and when you accept them, they turn into the corresponding symbol, like foo.opCmp(o) --> foo == o foo.opAdd(o) --> foo + o But I guess no one will find use in that.

i would! In fact this was my first thought when i read your post. i find this intuitive. As i work often work with eclipse, why not improve the content assistant when you press again strg+space (or what ever), instead of the template proposals, show the .op* symbols.

That's another interesting option. I wonder how to replace opApply, though: foo.opApply(...) --> foreach(a; c) { } ?
Apr 17 2008
parent Hendrik Renken <funsheep -[no-spam]-gmx.net> writes:
Ary Borenszweig schrieb:
 Hendrik Renken wrote:
 Ary Borenszweig wrote:
 Ary Borenszweig escribió:
 Bill Baxter escribió:
 Ary Borenszweig wrote:
 Hi,

 I'm improving Descent's autocompletion proposals, and I was
 wondering whether to show or hide methods such as opCmp, opEquals,
 opCall, etc.

 What do you think, should an IDE show these or not?

Can it show them only after someone types ".op" ? --bb

That's a good idea. What I'm looking for is some way to hide these methods, because you'd never want to write foo.opCmp(...) but you might just want to know which op* are defined for a given class. So your suggestion might be a solution. Thanks. :-)

Another way might be to show the op* methods, and when you accept them, they turn into the corresponding symbol, like foo.opCmp(o) --> foo == o foo.opAdd(o) --> foo + o But I guess no one will find use in that.

i would! In fact this was my first thought when i read your post. i find this intuitive. As i work often work with eclipse, why not improve the content assistant when you press again strg+space (or what ever), instead of the template proposals, show the .op* symbols.

That's another interesting option. I wonder how to replace opApply, though: foo.opApply(...) --> foreach(a; c) { ?

i suppose so. i would make two entries in the list. one with the method: foo.opMul(...) --> foo.opMul( ) and one with the operator: foo * bar --> foo * bar maybe just show the code that will appear when the entry is selected. and the entries depend on the implemented methods...
Apr 22 2008
prev sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Ary Borenszweig wrote:
 Ary Borenszweig escribió:
 Bill Baxter escribió:
 Can it show them only after someone types ".op" ?

That's a good idea.


Indeed, calling them explicitly is rarely useful (but see below)
 What I'm looking for is some way to hide these methods, because you'd 
 never want to write

 foo.opCmp(...)


A good reason (possibly the only one) to call opCmp explicitly is to implement an opCmp for a class/struct in terms of opCmp called on its members. The same goes for opApply by the way, the best use case I have for calling it explicitly is to implement opApply for a larger structure. For example, opApply for a binary tree could be implemented as "left.opApply(dg); dg(this.value); right.opApply(dg)" (and perhaps some null checks). This would prevent extra delegates being wrapped around "dg" as they would be by using "foreach(v; left) dg(v); dg(this.value); foreach(v; right) dg(v);".
 but you might just want to know which op* are defined for a given 
 class. So your suggestion might be a solution. Thanks. :-)

Another way might be to show the op* methods, and when you accept them, they turn into the corresponding symbol, like foo.opCmp(o) --> foo == o foo.opAdd(o) --> foo + o But I guess no one will find use in that.

That's a nice idea but it won't work for opCmp since it returns negative for less-than, zero for equal and positive for greater-than, while the comparison operators only return true or false. (And cast(bool)foo.opCmp(o) is the exact opposite of foo == o if opCmp and opEquals are implemented in a natural way) It could work for e.g. arithmetic operators though. But you'd need to be careful to make sure operator precedence doesn't screw things up. In other words: bar * foo.opAdd(baz) --> bar * (foo + baz) NOT: bar * foo.opAdd(baz) --> bar * foo + baz
Apr 21 2008