Inheritance of purity

[deadalnix]

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 !