Inheritance of purity

deadalnix deadalnix at
Sun Feb 26 04:02:14 PST 2012

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 fun;
>>>>> override void fun() { }
>>>>> }
>>>>> Alternatively:
>>>>> class B : A{
>>>>> override void fun()const{;}
>>>>> override void fun() { }
>>>>> }
>>>> So, back to the example above, someone will have to go throw the whole
>>>> codebase
>>>> and add override void fun()const{;} 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 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 !

More information about the Digitalmars-d mailing list