Mais je ne veux pas changer affiche(), puisque le but de l'héritage est justement de réutiliser le code! En plus, elle est très bien cette fonction: elle prend un objet de type A et appelle sa méthode toto. Je ne vois pas pourquoi elle aurait besoin d'être réécrite, surtout pour la restreindre aux objets de type B qui ne sont qu'un petit cas particulier des objets auxquels je veux l'appliquer!
Par ailleurs, ce n'est pas le problème de la classe de base qui a gêné pour pwlib. C'est avec le nouveau code que les problèmes sont apparus: comme les classes de base n'avaient pas prévu d'être héritées, il a fallu flanquer des virtual dans tous les coins pour obtenir un truc qui marche correctement. Apparemment il fallait connaître les futurs besoins avant de les avoir...
Ce que j'essaie d'expliquer depuis le début, c'est que la normalité quand on veut faire de l'héritage, c'est coder proprement ses classes de base pour faire ce qu'on veut dans un premier temps. Et dans un deuxième temps, quand de nouveaux besoins apparaissent, on hérite, on recode ce qu'il faut, éventuellement en signalant explicitement au compilateur qu'on modifie une méthode existante et ça marche *sans retoucher l'ancien code*. Ça c'est de l'héritage sérieux, et c'est un des ingrédients essentiels pour qualifier un langage 'd'orienté objets'. À partir du moment où il faut aller trifouiller l'ancien code pour faire marcher le nouveau, on ne peut pas dire que l'on gagne grand'chose à utiliser un langage 'à classes'...
Enfin, concernant le fait que les créateurs de langage soient des clowns: ça ne me semble pas si impossible que ça. Je connais au moins un architecte qui a conçu au moins un bâtiment dont une partie est à la fois accessible 24/24 7/7 et... dépourvue de toilettes!
[^] # Re: Langage objet...
Posté par Snark_Boojum . En réponse à la dépêche Les nouveautés de Qt 4. Évalué à 2.
Par ailleurs, ce n'est pas le problème de la classe de base qui a gêné pour pwlib. C'est avec le nouveau code que les problèmes sont apparus: comme les classes de base n'avaient pas prévu d'être héritées, il a fallu flanquer des virtual dans tous les coins pour obtenir un truc qui marche correctement. Apparemment il fallait connaître les futurs besoins avant de les avoir...
Ce que j'essaie d'expliquer depuis le début, c'est que la normalité quand on veut faire de l'héritage, c'est coder proprement ses classes de base pour faire ce qu'on veut dans un premier temps. Et dans un deuxième temps, quand de nouveaux besoins apparaissent, on hérite, on recode ce qu'il faut, éventuellement en signalant explicitement au compilateur qu'on modifie une méthode existante et ça marche *sans retoucher l'ancien code*. Ça c'est de l'héritage sérieux, et c'est un des ingrédients essentiels pour qualifier un langage 'd'orienté objets'. À partir du moment où il faut aller trifouiller l'ancien code pour faire marcher le nouveau, on ne peut pas dire que l'on gagne grand'chose à utiliser un langage 'à classes'...
Enfin, concernant le fait que les créateurs de langage soient des clowns: ça ne me semble pas si impossible que ça. Je connais au moins un architecte qui a conçu au moins un bâtiment dont une partie est à la fois accessible 24/24 7/7 et... dépourvue de toilettes!
Snark