Le 26/02/2012 00:02, Walter Bright a écrit :
> On 2/25/2012 2:16 PM, deadalnix wrote:
>> Le 25/02/2012 22:59, Walter Bright a écrit :
>>> On 2/25/2012 1:53 PM, deadalnix wrote:
>>>> Le 25/02/2012 22:25, Timon Gehr a écrit :
>>>>> By explicitly stating that he is aware of all the overloads:
>>>>>
>>>>> class B : A {
>>>>> alias A.fun fun;
>>>>> override void fun() { }
>>>>> }
>>>>>
>>>>> Alternatively:
>>>>>
>>>>> class B : A{
>>>>> override void fun()const{super.fun();}
>>>>> override void fun() { }
>>>>> }
>>>>
>>>> So, back to the example above, someone will have to go throw the whole
>>>> codebase
>>>> and add override void fun()const{super.fun();} all over the place to
>>>> fix the
>>>> broken code ?
>>>
>>>
>>> No, he can use the alias version.
>>
>> What would it look like ?
>
> class B : A {
> alias A.fun fun;
> override void fun() { }
> }

OK, but the problem remains equivalent. The programmer did modify in the base class something that is unrelated whith what is currently overridden in subclasses, and suddenly, all of them are broken. They all have to be fixed with an alias or a forwarding override.

I think this is an issue.

Thinking more about this, I did notice that I almost never do a const and a non const version of the same function when coding (either the functionality require const or it doesn't, so the const and non const version will do something very different, which is confusing).

Is it common ? If it is, it open the door to limiting override possibilities when it come to const.non const, with the advantage of being able to infer const in way more place than it is actually. I could expand about that.

PS: Ha nice, I got this English dictionary to work in my newsgroup client !

On Sunday, February 26, 2012 13:02:14 deadalnix wrote:
> Thinking more about this, I did notice that I almost never do a const and a non const version of the same function when coding (either the functionality require const or it doesn't, so the const and non const version will do something very different, which is confusing).
> 
> Is it common ? If it is, it open the door to limiting override possibilities when it come to const.non const, with the advantage of being able to infer const in way more place than it is actually. I could expand about that.

It's common for some stuff. A classic example would be iterators (or ranges). If you have a const reference or pointer to a container, then the iterator (or range) that you get out of it must give you const access to the elements, whereas a non-const reference or pointer to a container should be able to give you an iterator or range with mutable access to the elements.

One place that overloading on const in D could be very useful where it's of little use in C++ would be for caching. If you called a non-const version of a function, then the result could be cached (or the cached result used if the result isn't dirty), whereas while the const one could also use the cached version if it wasn't dirty, if the cached value was dirty, it would have to do the calculation without caching the result, since the object is const, and so it can't alter the cached value.

It _is_ true, however, that there are a lot of cases where it makes no sense to have both a const and non-const version of a function.

- Jonathan M Davis

Le 26/02/2012 13:17, Jonathan M Davis a écrit :
> On Sunday, February 26, 2012 13:02:14 deadalnix wrote:
>> Thinking more about this, I did notice that I almost never do a const
>> and a non const version of the same function when coding (either the
>> functionality require const or it doesn't, so the const and non const
>> version will do something very different, which is confusing).
>>
>> Is it common ? If it is, it open the door to limiting override
>> possibilities when it come to const.non const, with the advantage of
>> being able to infer const in way more place than it is actually. I could
>> expand about that.
>
> It's common for some stuff. A classic example would be iterators (or ranges).
> If you have a const reference or pointer to a container, then the iterator (or
> range) that you get out of it must give you const access to the elements,
> whereas a non-const reference or pointer to a container should be able to give
> you an iterator or range with mutable access to the elements.
>

Can't inout help us for such an issue ?

Le 26/02/2012 00:25, so a écrit :
> On Friday, 24 February 2012 at 00:01:52 UTC, F i L wrote:
>
>> Well then I disagree with Walter on this as well. What's wrong with
>> having a "standard" toolset in the same way you have standard
>> libraries? It's unrealistic to think people (at large) will be writing
>> any sort of serious application outside of a modern IDE. I'm not
>> saying it's Walters job to write IDE integration, only that the
>> language design shouldn't cater to the smaller use-case scenario.
>>
>> Cleaner code is easier to read and, within an IDE with tooltips, makes
>> little difference when looking at the hierarchy. If you want to be
>> hard-core about it, no one is stopping you from explicitly qualifying
>> each definition.
>
> Debugger is the single tool in VisualStudio that i failed to replace in
> unix land.
> I have tried many of them and they all sucked. They are either
> incomplete or crash too often. Command line gdb is not much of an
> option. The situation is so bad that looks like i need to go back to the
> VisualC++/gvim combo.

You have GUI that goes over gdb and are nice to use.

On Sunday, February 26, 2012 16:30:44 deadalnix wrote:
> Le 26/02/2012 13:17, Jonathan M Davis a écrit :
> > On Sunday, February 26, 2012 13:02:14 deadalnix wrote:
> >> Thinking more about this, I did notice that I almost never do a const and a non const version of the same function when coding (either the functionality require const or it doesn't, so the const and non const version will do something very different, which is confusing).
> >> 
> >> Is it common ? If it is, it open the door to limiting override possibilities when it come to const.non const, with the advantage of being able to infer const in way more place than it is actually. I could expand about that.
> > 
> > It's common for some stuff. A classic example would be iterators (or ranges). If you have a const reference or pointer to a container, then the iterator (or range) that you get out of it must give you const access to the elements, whereas a non-const reference or pointer to a container should be able to give you an iterator or range with mutable access to the elements.
> 
> Can't inout help us for such an issue ?

Probably. I'm not very well versed in inout though. But it _is_ likely that inout solves at least some issues which would require you to overload on const.

- Jonathan M Davis

On Sunday, 26 February 2012 at 15:25:44 UTC, deadalnix wrote:
> Le 26/02/2012 00:25, so a écrit :

> You have GUI that goes over gdb and are nice to use.

You mean DDD (which i think best of them)? Indeed nice, but it crashes too often.

"so" <so@so.so> wrote in message news:otgdfqnpnpbfxuegmlnn@forum.dlang.org...
> On Sunday, 26 February 2012 at 15:25:44 UTC, deadalnix wrote:
>> Le 26/02/2012 00:25, so a écrit :
>
>> You have GUI that goes over gdb and are nice to use.
>
> You mean DDD (which i think best of them)? Indeed nice, but it crashes too often.
>

I spent hours trying to get disassembly working in ddd yesterday, in the end I gave up and used gdb.  I hope I never have to leave visual studio 6 again.

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jibpa0$vt$1@digitalmars.com...
>
> Not using override is currently deprecated. Eventually, it will be required.
>

It's still in the 'warning' stage.  It would be nice to know when it's actually going to become properly deprecated.

On Sunday, 26 February 2012 at 16:47:33 UTC, Daniel Murphy wrote:

> I spent hours trying to get disassembly working in ddd yesterday, in the end
> I gave up and used gdb.  I hope I never have to leave visual studio 6 again.

There is always Kdevelop if you want IDE. Awesome piece of free software.
It now has vim mode, if only it was supported it fully!

"so" <so@so.so> wrote in message news:qazgjukeorotmmdqdmkj@forum.dlang.org...
> On Sunday, 26 February 2012 at 16:47:33 UTC, Daniel Murphy wrote:
>
>> I spent hours trying to get disassembly working in ddd yesterday, in the
>> end
>> I gave up and used gdb.  I hope I never have to leave visual studio 6
>> again.
>
> There is always Kdevelop if you want IDE. Awesome piece of free software. It now has vim mode, if only it was supported it fully!

Thanks, I'll give that a go next time I need to do something with D on x64.