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?

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

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. :-)

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.

On Sun, 13 Apr 2008 23:16:48 +0200, Ary Borenszweig <ary@esperanto.org.ar> 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.

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

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.

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) {
                     }

?

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

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...