Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
April 13, 2008 Poll: show op* or not in autocompletion? | ||||
---|---|---|---|---|
| ||||
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? |
April 13, 2008 Re: Poll: show op* or not in autocompletion? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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
|
April 13, 2008 Re: Poll: show op* or not in autocompletion? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | 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. :-)
|
April 13, 2008 Re: Poll: show op* or not in autocompletion? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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.
|
April 13, 2008 Re: Poll: show op* or not in autocompletion? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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
|
April 17, 2008 Re: Poll: show op* or not in autocompletion? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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.
|
April 17, 2008 Re: Poll: show op* or not in autocompletion? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Hendrik Renken | 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) {
}
?
|
April 21, 2008 Re: Poll: show op* or not in autocompletion? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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 |
April 22, 2008 Re: Poll: show op* or not in autocompletion? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ary Borenszweig | 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...
|
Copyright © 1999-2021 by the D Language Foundation