Attention, je ne parle pas de virtual vs final, mais de la sémantique des appels, i.e., le fait que le polymorphisme ne "fonctionne pas" toujours.
Sinon, les explications données ne sont pas très convainquantes :
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.
C'est grotesque, mais malheureusement ça a la vie dure. Oui, il y a un léger overhead quand on utilise une méthode virtual. Mais ce n'est surtout pas au programmeur de s'en occuper ! Ca fait des années (7 ans dans le cas de SmallEiffel et 10 dans le cas de Sather), qu'on sait faire des optimisations globales qui permettent de virer les virtual inutiles (ou de rendre final les méthodes concernées, si tu préfères). Non seulement cela permet au programmeur de ne pas se soucier du problème d'efficacité, mais en plus cela permet de faire des optimisations locales. Par exemple dans un morceau de code, on peut virer les virtual et inliner les méthodes concernées, alors que dans un autre boût de code du même programme, on doit garder le late binding. Bref, il est impossible de faire ça à la main. Cf les articles des auteurs de SmallEiffel (http://smarteiffel.loria.fr/papers/papers.html(...)).
Quant à la seconde partie, elle est intéressante, mais je doute qu'on puisse faire de la théorie là dessus. Mon expérience personnelle est qu'en C++, je finaissais par presque tout mettre en virtual, sauf les méthodes pour lesquelles cela aurait pu potentiellement casser le reste du programme.
Mais encore une fois, en fait on s'en fout un peu. Le point important est qu'en C#, on peut avoir un comportement différent pour un objet selon le type de la variable qui contient la référence vers l'objet, alors que c'est impossible en Java. Personnellement, je trouve ça plutôt gênant et surtout, je ne vois pas d'application pratique.
[^] # Re: C'est un troll.
Posté par boubou . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Sinon, les explications données ne sont pas très convainquantes :
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.
C'est grotesque, mais malheureusement ça a la vie dure. Oui, il y a un léger overhead quand on utilise une méthode virtual. Mais ce n'est surtout pas au programmeur de s'en occuper ! Ca fait des années (7 ans dans le cas de SmallEiffel et 10 dans le cas de Sather), qu'on sait faire des optimisations globales qui permettent de virer les virtual inutiles (ou de rendre final les méthodes concernées, si tu préfères). Non seulement cela permet au programmeur de ne pas se soucier du problème d'efficacité, mais en plus cela permet de faire des optimisations locales. Par exemple dans un morceau de code, on peut virer les virtual et inliner les méthodes concernées, alors que dans un autre boût de code du même programme, on doit garder le late binding. Bref, il est impossible de faire ça à la main. Cf les articles des auteurs de SmallEiffel (http://smarteiffel.loria.fr/papers/papers.html(...)).
Quant à la seconde partie, elle est intéressante, mais je doute qu'on puisse faire de la théorie là dessus. Mon expérience personnelle est qu'en C++, je finaissais par presque tout mettre en virtual, sauf les méthodes pour lesquelles cela aurait pu potentiellement casser le reste du programme.
Mais encore une fois, en fait on s'en fout un peu. Le point important est qu'en C#, on peut avoir un comportement différent pour un objet selon le type de la variable qui contient la référence vers l'objet, alors que c'est impossible en Java. Personnellement, je trouve ça plutôt gênant et surtout, je ne vois pas d'application pratique.