View mode: basic / threaded / horizontal-split · Log in · Help
August 05, 2007
Re: Overloading/Inheritance issue
Walter Bright wrote:
> 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 optimizing your language for vi and the printer is a dead-end. 
The vast majority of the time a developer is going to be working on his 
code on a computer using some tool.  If a tool lets you make use of a 
big productivity feature, then it makes sense to use it and officially 
endorse it as a basic requirement of the language.  Even vi users use 
tools like grep and ctags.

-Jeff
August 05, 2007
Re: Overloading/Inheritance issue
Walter Bright wrote:
> 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).
> 

Auditing, as in someone review someone else's code? Well, yes, in that 
case that tool functionality wouldn't be that useful (although other 
functionalities might be), however, auditing is a very specific 
situation, as well has it has lots of other difficulties which aren't 
easy to handle.

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

"rarely used"?? Wait, what do you mean "add-on tools"? That 
functionality is part of JDT (the best (non-commercial) and most popular 
Java IDE), and similar functionality exists in other IDEs for other 
languages, so it's quite the opposite of rarely used.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
August 05, 2007
Re: Overloading/Inheritance issue
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.
August 05, 2007
Re: Overloading/Inheritance issue
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
August 05, 2007
Re: Overloading/Inheritance issue
Jeff Nowakowski wrote:
> I think optimizing your language for vi and the printer is a dead-end. 
> The vast majority of the time a developer is going to be working on his 
> code on a computer using some tool.  If a tool lets you make use of a 
> big productivity feature, then it makes sense to use it and officially 
> endorse it as a basic requirement of the language.  Even vi users use 
> tools like grep and ctags.

Everyone uses different tools, and particular tools may not be available 
 on all platforms D is on.

FWIW, a lot of hard core programmers still use vi.
August 05, 2007
Re: Overloading/Inheritance issue
Bruno Medeiros wrote:
> Walter Bright wrote:
>> 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).
>>
> 
> Auditing, as in someone review someone else's code?

Yes. This is done a lot in professional programming environments, and in 
particular in cases where high reliability/security is needed. C++ is a 
very expensive language to audit because of, for example, the nearly 
nonexistent modularity.

> Well, yes, in that 
> case that tool functionality wouldn't be that useful (although other 
> functionalities might be), however, auditing is a very specific 
> situation, as well has it has lots of other difficulties which aren't 
> easy to handle.

I think that when a language is more auditable, it is more attractive 
for uses that demand high reliability or security. Auditability has 
definitely been a goal of D since the beginning. I've worked with 
programmers from the corporate Java world who have told me about 
auditability problems with Java that makes their life much more difficult.

>> 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.
> 
> "rarely used"?? Wait, what do you mean "add-on tools"? That 
> functionality is part of JDT (the best (non-commercial) and most popular 
> Java IDE), and similar functionality exists in other IDEs for other 
> languages, so it's quite the opposite of rarely used.

Let me put it another way. How many people use a profiler? coverage 
analyser? Those tools are built-in, are extremely useful, yet are still 
rarely used.
August 05, 2007
Re: Overloading/Inheritance issue
Walter Bright wrote:
> Jeff Nowakowski wrote:
>> I think optimizing your language for vi and the printer is a dead-end. 
>> The vast majority of the time a developer is going to be working on 
>> his code on a computer using some tool.  If a tool lets you make use 
>> of a big productivity feature, then it makes sense to use it and 
>> officially endorse it as a basic requirement of the language.  Even vi 
>> users use tools like grep and ctags.
> 
> Everyone uses different tools, and particular tools may not be available 
>  on all platforms D is on.
> 
> FWIW, a lot of hard core programmers still use vi.

I use emacs at work.  Sun Studio (the obvious alternative) is too slow 
and I don't care about any of the features it offers over a plain text 
editor combined with command-line tools (grep, etc).


Sean
August 05, 2007
Re: Overloading/Inheritance issue
Reply to Chris Nicholson-Sauls,

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

Unless I'm totally misreading you, that IS how it works.
August 05, 2007
Re: Overloading/Inheritance issue
Reply to Walter,

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


In code review, you may have a point. In writing code? Now that is one thing 
Microsoft got RIGHT!! Visual Studio rocks in that regard.

Now it they just had a feature that (automatically without me asking for 
it) gives me a list of cases where a code change resulted in a different 
overload resolution... It would make a nice feature in a diff tool as well.
August 05, 2007
Re: Overloading/Inheritance issue
Walter Bright wrote:
> 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.

It might be neat to define an API for the compiler.  I mean an api that 
would let you write programs that link to d-compiler.lib to do various 
things like get an AST etc.  I know D syntax tries to be easy to parse, 
but why not just have the spec also specify an api for would-be D 
compilers.  Giving a compiler a well defined API is not really something 
specific to D but it would make a lot of things easier.

--bb
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home