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