Hopefully I have something new to add to the argument

Robert DaSilva sp.unit.262+digitalmars at gmail.com
Sun Jan 6 16:25:52 PST 2008


Jason House wrote:
> Sean Kelly wrote:
> 
>> Sean Reque wrote:
>>> Thanks for the links! I was able to find through it two very long
>>> discussions on this issue. One point that was brought up is that the
>>> reason D implements overload resolution the way it currently does is
>>> because c++ did it the same way for 20 years and no one complained. Well,
>>> a lot of post were made about different aspects of the issue, so I want
>>> to just focus on the area I have the biggest problem with. I didn't read
>>> EVERY post, but I hope this is a newer way of looking at it.
>> Here are some of the posts that I was thinking of in particular:
>>
>>
> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=56391
> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=56414
> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=56418
>> The different overload resolution schemes between C++ and D may be a
>> factor as well.
>>
>>
>> Sean
> 
> Wow...  That's a pretty evil bug.  I think I have to agree with Sean Reque
> in that this type of thing really can't sit around as a bomb at runtime.
> 
> I was under the impression that shadowing superclass functions was an ERROR
> and that if a function was to be defined with the same name that it had to
> use the override keyword to make the programmer's intent clear.  I'm almost
> certain that shadowing variables in functions is an ERROR.  This seems even
> more evil.
> 
> I'd really, really hope that a language that includes design by contract,
> unit testing, and enhanced const correctness would do a better job handling
> this class of problem.  I'd expect some kind of specialized syntax to mark
> this type of questionable code as the programmer's intent.  It seems to me
> that in the squareIt example, accessing a D instance via a B reference
> should be illegal...
> 
> Maybe I should go back and read that whole thread on this topic before I
> post more...

This happen when you overRIDE an overLOADed function, but you don't
overRIDE all of the overLOADs.



More information about the Digitalmars-d mailing list