Overloading/Inheritance issue

[Chris Nicholson-Sauls]

Ary Manzana wrote:
> Walter Bright escribió:
>> Bruno Medeiros wrote:
>>> Walter Bright wrote:
>>>>
>>>> 4) Having overloads spread across the inheritance hierarchy makes 
>>>> the source code resistant to visual audits. For any method call, 
>>>> you'll have to look at EVERY base class to see if it has an overload 
>>>> that is a better match.
>>>>
>>>
>>> I'm not sure if you've seen my other reply to this argument, but let 
>>> be more explicit, with pictures. Let's say you have such a big 
>>> inheritance hierarchy, with overloads spread across it.
>>
>> I appreciate that you can write tools to analyze it. I think they help 
>> a lot in writing the code, but I don't think they are as helpful for 
>> auditing (code review).
>>
>> Another problem with them is they are not part of the D compiler 
>> itself, and in my experience add on tools rarely get used, no matter 
>> how useful they are.
> 
> I think it's the opposite. In every workplace I've been, people can't 
> live with a decent IDE.

For most things I do just fine without an IDE.  For all my work with D, 
PHP, ... well nearly everything, I use EditPlus which provides next to 
nothing beyond very basic keyword highlighting.  Its enough.  :) 
(Actually he added simplistic code folding in the last release... that I 
do like, but I digress.)  For Ruby I use SciTE which is little more than 
a glorified notepad/edit with respectably elaborate highlighting.  (I 
use that for Ruby because it can handle some special cases such as #{} 
expressions within strings.)

The only language I crave an IDE for... is Java.  Just for 
dot-code-completion, and then only because the standard library so such 
huge.  (Okay... so Ruby has a pretty extensive set as well, but its not 
so unapproachably big as Java's.)

That being said...  I do like to run tools to generate "meta-data" and 
other reports from code which I can use to review it.  Even to the 
extent of sometimes coding my own.  (Wrote a little thing to generate 
HTML files from a LambdaMOO database once.  Made working on a MOO a 
little saner.)

So I think the primary argument is still sound in favor of tools, 
although I'm slipping back toward neutrality on this matter of 
inheritance and overloading...  turns out Walter is right about one 
important thing at the very least: it can definitely be argued, and 
argued well, in either direction.  At least aliases are a quick and 
simple "fix".

What we really need is a fix for the problem of casting to a Base class 
"forgetting" overrides.  Maybe a change to how vtbls work?  Okay, an 
example:

class Base {
   int foo () { return 1; }
}

class Derived : Base {
   override int foo () { return 2; }
}

What I'm thinking, is that Derived's copy of Base's vtbl should have the 
pointer for .foo replaced with a pointer to its override.  That way, 
when cast to Base the entry still points to Derived's method.  Assuming 
the vtbl is prepared at compile-time, this shouldn't cause any runtime 
issues... should it?

-- Chris Nicholson-Sauls