View mode: basic / threaded / horizontal-split · Log in · Help
February 26, 2012
Re: Inheritance of purity
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 !
February 26, 2012
Re: Inheritance of purity
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
February 26, 2012
Re: Inheritance of purity
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 ?
February 26, 2012
Re: Inheritance of purity
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.
February 26, 2012
Re: Inheritance of purity
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
February 26, 2012
Re: Inheritance of purity
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.
February 26, 2012
Re: Inheritance of purity
"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.
February 26, 2012
Re: Inheritance of purity
"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.
February 26, 2012
Re: Inheritance of purity
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!
February 26, 2012
Re: Inheritance of purity
"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.
8 9 10 11 12 13
Top | Discussion index | About this forum | D home