sean reque wrote:

> crashing behavior is part of the 2.0 spec.

oops. Should have read your original post.

-manfred

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...

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.

Robert DaSilva wrote:
> This happen when you overRIDE an overLOADed function, but you don't overRIDE all of the overLOADs.

That sounds like something very easy to detect at compile-time.  Are there practical situations with large ovrload sets where this would be a real pain for the programmer?

Jason House wrote:
> Robert DaSilva wrote:
>> This happen when you overRIDE an overLOADed function, but you don't
>> overRIDE all of the overLOADs.
> 
> That sounds like something very easy to detect at compile-time.  Are there
> practical situations with large ovrload sets where this would be a real
> pain for the programmer?

In general, it's a bad idea to have overloaded virtual functions.
A virtual function is a customization point; having overloads means
that each customization has to be sure to overload them all in a
consistent manner.  Much better to have non-virtual overloads which
forward to a single, general, virtual function.  Then the problem
disappears.  I think that diagnosing overloaded virtuals would be
entirely reasonable.

-- James

On 1/7/08, James Dennett <jdennett@acm.org> wrote:
> In general, it's a bad idea to have overloaded virtual functions.

Perhaps, but this is D, where member functions are virtual by default.

Janice Caron wrote:
> On 1/7/08, James Dennett <jdennett@acm.org> wrote:
>> In general, it's a bad idea to have overloaded virtual functions.
> 
> Perhaps, but this is D, where member functions are virtual by default.

That's OK, it just makes writing safe code take a little more
effort.  Writing safe code has always taken effort.  Sure, it's
nice when the language helped rather than hindered, but no one
language will get all trade-offs right.

There are other reasons why a _programmer's_ default should be
to make a function non-virtual, most significantly that writing
(and designing) a solid specification for virtual functions is
harder than for non-virtual functions as they have three
components: what the default implementation does, what an
override is required to do, and what the override is not allowed
to do (e.g., if it's called when the object is not in a state
which permits calling certain other methods on it).  Most
functions don't need that much complexity, and a type which
has mostly virtual functions almost never has adequate documentation
unless it's a pure interface.

-- James

James Dennett Wrote:
ps, but this is D, where member functions are virtual by default.
> 
> That's OK, it just makes writing safe code take a little more effort.

Well if everyone is agreed that virtual function overriding is a bad idea, could we at least get some kind of a warning message at compile time when it happens? If the compiler is smart enough to stuff the v-table with garbage functions, it could also inform us that it is doing so. Of course, I still don't agree that the compiler shouldn't be placing the --correct-- functions in the v-table. The way it is now, whenever a programmer decides to create a class that inherits from another, he has to understand the entire class hierarchy of that inherited class to be sure he doesn't accidentally override a function that disables the class from taking advantage of inclusion polymorphism.

This HiddenFuncError feature breaks inclusion polymorphism, because having a class B inherit from class A no longer implies that an object of type B is fully capable of acting as an object of type A, regardless of whether or not the programmer intended to make it that way. That's a huge deal, because most of the advantage of OOP comes from this type of polymorphism, more so than encapsulation and data-aggregation.   The fact that this important piece of information is only revealed under specific conditions at runtime is what makes it so dangerous. In my opinion, this alone makes D OOP inferior to that of most other modern languages.

If this is going to be a permanent feature,  then there should at least be a way to get a warning at compile time that a class is hiding functions from a superclass, which could cause your entire program to crash.

Sean Reque wrote:
> Well if everyone is agreed that virtual function overriding is a bad idea, could we at least get some kind of a warning message at compile time when it happens?

Warnings aren't part of the D spec, so compilers are free to implement them however thy like.