On 6/5/2013 6:08 PM, deadalnix wrote:
> History also showed us that C# introduced way to revirtualize method, for
> several purposes like mock. We can't simple take this argument and don't look at
> it with the light of history.

This is an interesting point that I didn't know about and didn't think of.

Is there an article about it that goes into some depth about the rationale?

On 6/5/2013 5:49 PM, deadalnix wrote:
> The first point : Anders Hejlsberg: There are several reasons. One is
> performance. We can observe that as people write code in Java, they forget to
> mark their methods final. Therefore, those methods are virtual. Because they're
> virtual, they don't perform as well. There's just performance overhead
> associated with being a virtual method. That's one issue.
>
> It is blatantly false. Maybe it was true at the time, I don't know, but I find
> quite disturbing that the first argument is 100% moot.


It may very well be false for JIT systems, but for native code, we already discussed that auto-finalization is unlikely to be practical for D.

On 6/6/2013 11:11 AM, deadalnix wrote:
> It is also possible to automatically generate code like :
> if (virtualMethod == givenMethod) {
>      givenMethod();
> } else {
>      virtualMethod();
> }
>
> It sound like it is completely stupid, but in fact, as the compiler know the
> call you'll do, it can run optimizations.

You're right, that is a valid optimization for virtual methods. But, it is not as good as final, because the call to virtualMethod() negatively affects the code generation even if it is never called.

(This is because of things like function calls destroy the scratch registers, meaning that variables can't easily be enregistered into them.)

Ok, Manu, you win, I'm pretty much convinced.

On 6/6/13 2:20 PM, Walter Bright wrote:
> On 6/5/2013 5:49 PM, deadalnix wrote:
>> The first point : Anders Hejlsberg: There are several reasons. One is
>> performance. We can observe that as people write code in Java, they
>> forget to
>> mark their methods final. Therefore, those methods are virtual.
>> Because they're
>> virtual, they don't perform as well. There's just performance overhead
>> associated with being a virtual method. That's one issue.
>>
>> It is blatantly false. Maybe it was true at the time, I don't know,
>> but I find
>> quite disturbing that the first argument is 100% moot.
>
>
> It may very well be false for JIT systems, but for native code, we
> already discussed that auto-finalization is unlikely to be practical for D.

I think class hierarchy analysis is very doable for whole D projects. You just pass the tool all files in the project and it does its thing.

http://www.cs.ucla.edu/~palsberg/tba/papers/dean-grove-chambers-ecoop95.pdf

This would actually be a great GSoC-style project, distributable via tools/.


Andrei

On Thursday, June 06, 2013 11:19:52 Walter Bright wrote:
> On 6/5/2013 6:08 PM, deadalnix wrote:
> > History also showed us that C# introduced way to revirtualize method, for several purposes like mock. We can't simple take this argument and don't look at it with the light of history.
> 
> This is an interesting point that I didn't know about and didn't think of.

>From other comments in this thread, it sounds like C# was doing stuff to better
enable mock objects, but it also sounds like they didn't really revirtualize methods so much as provide was of replacing them (since revirtualizing them wouldn't help with stuff like static methods).

> Is there an article about it that goes into some depth about the rationale?

If we wanted a more in-depth understanding of what C# did, we'd definitely need such an article - especially for those of us who don't know all that much about C#.

- Jonathan M Davis

On 6/6/2013 11:27 AM, Walter Bright wrote:
> On 6/6/2013 11:11 AM, deadalnix wrote:
>> It is also possible to automatically generate code like :
>> if (virtualMethod == givenMethod) {
>>      givenMethod();
>> } else {
>>      virtualMethod();
>> }
>>
>> It sound like it is completely stupid, but in fact, as the compiler know the
>> call you'll do, it can run optimizations.
>
> You're right, that is a valid optimization for virtual methods.

(Also, this is often done as a profile guided optimization, with givenMethod being the most often case.)

On 6/6/2013 12:31 PM, Andrei Alexandrescu wrote:
> I think class hierarchy analysis is very doable for whole D projects. You just
> pass the tool all files in the project and it does its thing.
>
> http://www.cs.ucla.edu/~palsberg/tba/papers/dean-grove-chambers-ecoop95.pdf
>
> This would actually be a great GSoC-style project, distributable via tools/.

The trouble, as has been pointed out before, is shared libraries.

On Thursday, June 06, 2013 12:37:12 Walter Bright wrote:
> On 6/6/2013 12:31 PM, Andrei Alexandrescu wrote:
> > I think class hierarchy analysis is very doable for whole D projects. You just pass the tool all files in the project and it does its thing.
> > 
> > http://www.cs.ucla.edu/~palsberg/tba/papers/dean-grove-chambers-ecoop95.pd f
> > 
> > This would actually be a great GSoC-style project, distributable via tools/.
> The trouble, as has been pointed out before, is shared libraries.

Yes. Especially those which are dynamically loaded while the program is running.

What you _could_ do is have a program which looked over your code and pointed out which functions which probably didn't need to be virtual, but it would still need to be up to the programmer to actually make the change, since the program could easily be wrong.

- Jonathan M Davis

On 6/6/13 2:31 PM, Walter Bright wrote:
> Ok, Manu, you win, I'm pretty much convinced.

In my heart of hearts I somehow hope this will blow over and we'll get to some actually interesting stuff...

Andrei