Autre fantasme, le choix des langages est parfaitement rationnel et
purement technique... je parie que les criteres non-rationnels ou
non-technique (quand ils ne sont pas a la fois non-rationnels et
non-techniques) dominent. Naturellement, on peut les rationnaliser
techniquement apres coup, mais rationnaliser une autre decision serait tout
aussi facile.
Autre fantasme, le choix des langages est parfaitement rationnel et
purement technique... je parie que les criteres non-rationnels ou
non-technique (quand ils ne sont pas a la fois non-rationnels et
non-techniques) dominent. Naturellement, on peut les rationnaliser
techniquement apres coup, mais rationnaliser une autre decision serait tout
aussi facile.
Autre fantasme, le choix des langages est parfaitement rationnel et
purement technique... je parie que les criteres non-rationnels ou
non-technique (quand ils ne sont pas a la fois non-rationnels et
non-techniques) dominent. Naturellement, on peut les rationnaliser
techniquement apres coup, mais rationnaliser une autre decision serait tout
aussi facile.
In article <48bbfa8b$0$927$,
Wykaaa wrote:Oh là. Tu y vas fort quand même.
Si on prend le modèle COCOMO d'estimation des HM en fonction du nombre
de lignes de code estimées et des différents facteurs de coût, on voit
que les formules ne sont pas linéaires, justement parce que, par
exemple, 6 * 20 HM ne sont pas équivalents à 12 * 10 HM ce que montre,
justement, Frederick Brooks dans son livre "The mythical Man-Month".
Comme tu peux t'en douter, je suis contre la mecanisation a outrance
du travail en informatique, une forme de taylorisme de plus.
Il y a deux sortes de projets en informatique:
- les trucs triviaux, que tu vas filer a un pisseur de code java/C#/vbasic,
et qui va quand meme arriver a te le planter parce qu'il ne sait pas lire.
- les trucs interessants, qui sont presque infaisables.
Le premier cas se mecanise et se deshumanise tres bien. Appliquer des
techniques de management un peu cretines au 2e cas ne fonctionne pas trop...
Evidemment, le premier cas correspond a environ 90% du chiffre d'affaires
actuel de l'informatique... je ne sais pas trop s'il faut s'en rejouir ou
en pleurer, mais perso, je prefere faire des trucs qui appartiennent a la
2e categorie.
In article <48bbfa8b$0$927$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Oh là. Tu y vas fort quand même.
Si on prend le modèle COCOMO d'estimation des HM en fonction du nombre
de lignes de code estimées et des différents facteurs de coût, on voit
que les formules ne sont pas linéaires, justement parce que, par
exemple, 6 * 20 HM ne sont pas équivalents à 12 * 10 HM ce que montre,
justement, Frederick Brooks dans son livre "The mythical Man-Month".
Comme tu peux t'en douter, je suis contre la mecanisation a outrance
du travail en informatique, une forme de taylorisme de plus.
Il y a deux sortes de projets en informatique:
- les trucs triviaux, que tu vas filer a un pisseur de code java/C#/vbasic,
et qui va quand meme arriver a te le planter parce qu'il ne sait pas lire.
- les trucs interessants, qui sont presque infaisables.
Le premier cas se mecanise et se deshumanise tres bien. Appliquer des
techniques de management un peu cretines au 2e cas ne fonctionne pas trop...
Evidemment, le premier cas correspond a environ 90% du chiffre d'affaires
actuel de l'informatique... je ne sais pas trop s'il faut s'en rejouir ou
en pleurer, mais perso, je prefere faire des trucs qui appartiennent a la
2e categorie.
In article <48bbfa8b$0$927$,
Wykaaa wrote:Oh là. Tu y vas fort quand même.
Si on prend le modèle COCOMO d'estimation des HM en fonction du nombre
de lignes de code estimées et des différents facteurs de coût, on voit
que les formules ne sont pas linéaires, justement parce que, par
exemple, 6 * 20 HM ne sont pas équivalents à 12 * 10 HM ce que montre,
justement, Frederick Brooks dans son livre "The mythical Man-Month".
Comme tu peux t'en douter, je suis contre la mecanisation a outrance
du travail en informatique, une forme de taylorisme de plus.
Il y a deux sortes de projets en informatique:
- les trucs triviaux, que tu vas filer a un pisseur de code java/C#/vbasic,
et qui va quand meme arriver a te le planter parce qu'il ne sait pas lire.
- les trucs interessants, qui sont presque infaisables.
Le premier cas se mecanise et se deshumanise tres bien. Appliquer des
techniques de management un peu cretines au 2e cas ne fonctionne pas trop...
Evidemment, le premier cas correspond a environ 90% du chiffre d'affaires
actuel de l'informatique... je ne sais pas trop s'il faut s'en rejouir ou
en pleurer, mais perso, je prefere faire des trucs qui appartiennent a la
2e categorie.
In article ,
Jean-Marc Bourguet wrote:Autre fantasme, le choix des langages est parfaitement rationnel et
purement technique... je parie que les criteres non-rationnels ou
non-technique (quand ils ne sont pas a la fois non-rationnels et
non-techniques) dominent. Naturellement, on peut les rationnaliser
techniquement apres coup, mais rationnaliser une autre decision serait tout
aussi facile.
Bof, sur un projet `recent', le choix du langage etait parfaitement lucide
et rationnel. J'ai reecrit un outil de C en perl.
Les raisons:
- le code de depart etait tres buggue vis-a-vis de certaines contraintes
(gestion correcte de chaine de caracteres)
- avoir une gestion simple de chaines et de regexp etait un plus appreciable
- j'avais un eventail de langages restreint sous la main (necessite d'etre
dans le systeme de base d'OpenBSD)
- perl est un langage que je connais bien.
Apres coup, le resultat est excellent. Comme attendu, moins de bugs que la
version C (nettement) et un outil bien plus rapide (meilleurs algos, et
performance dominee par les entrees-sorties de toutes facons). Le seul
gros defaut qu'on a trouve, c'est que c'est du code perl assez avance, et
que peu de monde maitrise l'OO en perl...
In article <pxbtzd0x82s.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> wrote:
Autre fantasme, le choix des langages est parfaitement rationnel et
purement technique... je parie que les criteres non-rationnels ou
non-technique (quand ils ne sont pas a la fois non-rationnels et
non-techniques) dominent. Naturellement, on peut les rationnaliser
techniquement apres coup, mais rationnaliser une autre decision serait tout
aussi facile.
Bof, sur un projet `recent', le choix du langage etait parfaitement lucide
et rationnel. J'ai reecrit un outil de C en perl.
Les raisons:
- le code de depart etait tres buggue vis-a-vis de certaines contraintes
(gestion correcte de chaine de caracteres)
- avoir une gestion simple de chaines et de regexp etait un plus appreciable
- j'avais un eventail de langages restreint sous la main (necessite d'etre
dans le systeme de base d'OpenBSD)
- perl est un langage que je connais bien.
Apres coup, le resultat est excellent. Comme attendu, moins de bugs que la
version C (nettement) et un outil bien plus rapide (meilleurs algos, et
performance dominee par les entrees-sorties de toutes facons). Le seul
gros defaut qu'on a trouve, c'est que c'est du code perl assez avance, et
que peu de monde maitrise l'OO en perl...
In article ,
Jean-Marc Bourguet wrote:Autre fantasme, le choix des langages est parfaitement rationnel et
purement technique... je parie que les criteres non-rationnels ou
non-technique (quand ils ne sont pas a la fois non-rationnels et
non-techniques) dominent. Naturellement, on peut les rationnaliser
techniquement apres coup, mais rationnaliser une autre decision serait tout
aussi facile.
Bof, sur un projet `recent', le choix du langage etait parfaitement lucide
et rationnel. J'ai reecrit un outil de C en perl.
Les raisons:
- le code de depart etait tres buggue vis-a-vis de certaines contraintes
(gestion correcte de chaine de caracteres)
- avoir une gestion simple de chaines et de regexp etait un plus appreciable
- j'avais un eventail de langages restreint sous la main (necessite d'etre
dans le systeme de base d'OpenBSD)
- perl est un langage que je connais bien.
Apres coup, le resultat est excellent. Comme attendu, moins de bugs que la
version C (nettement) et un outil bien plus rapide (meilleurs algos, et
performance dominee par les entrees-sorties de toutes facons). Le seul
gros defaut qu'on a trouve, c'est que c'est du code perl assez avance, et
que peu de monde maitrise l'OO en perl...
Peu de monde maîtrise réellement l'OO de toute façon, hélas...
Peu de monde maîtrise réellement l'OO de toute façon, hélas...
Peu de monde maîtrise réellement l'OO de toute façon, hélas...
"crise du logiciel", il cite des projets d'ampleurs croissantes (j'ai
pas compris ses unités hommes/ mois) :
Compilateur (C, Pascal...) -> 120 HM
Compilateur ADA -> 1800 HM
Logiciel Navette -> 12000 HM
Système d'exploitation -> 60000 HM
Bon, justement, un des logiciels les plus complexes est un OS. Or, des
OS comme Linux
ou Windows pour x86 sont en général écrit majoritairement en C avec
de l'assembleur dans de petites proportions.
Donc, ma question est : pourquoi ne réécrit-on from scratch pas les OS
dans un langage objet genre C++ ?
Autre question dans le même registre : comment se fait-il que les
implémentations de langage objets comme Python et Ruby soient écrits
en C et non pas en C++ ?
"crise du logiciel", il cite des projets d'ampleurs croissantes (j'ai
pas compris ses unités hommes/ mois) :
Compilateur (C, Pascal...) -> 120 HM
Compilateur ADA -> 1800 HM
Logiciel Navette -> 12000 HM
Système d'exploitation -> 60000 HM
Bon, justement, un des logiciels les plus complexes est un OS. Or, des
OS comme Linux
ou Windows pour x86 sont en général écrit majoritairement en C avec
de l'assembleur dans de petites proportions.
Donc, ma question est : pourquoi ne réécrit-on from scratch pas les OS
dans un langage objet genre C++ ?
Autre question dans le même registre : comment se fait-il que les
implémentations de langage objets comme Python et Ruby soient écrits
en C et non pas en C++ ?
"crise du logiciel", il cite des projets d'ampleurs croissantes (j'ai
pas compris ses unités hommes/ mois) :
Compilateur (C, Pascal...) -> 120 HM
Compilateur ADA -> 1800 HM
Logiciel Navette -> 12000 HM
Système d'exploitation -> 60000 HM
Bon, justement, un des logiciels les plus complexes est un OS. Or, des
OS comme Linux
ou Windows pour x86 sont en général écrit majoritairement en C avec
de l'assembleur dans de petites proportions.
Donc, ma question est : pourquoi ne réécrit-on from scratch pas les OS
dans un langage objet genre C++ ?
Autre question dans le même registre : comment se fait-il que les
implémentations de langage objets comme Python et Ruby soient écrits
en C et non pas en C++ ?
In article <48bc0673$0$949$,
Wykaaa wrote:Peu de monde maîtrise réellement l'OO de toute façon, hélas...
Je conseille tres fortement le bouquin
_Refactoring: improving the design of existing code_, de Martin Fowler
(ISBN 0-201-48567-2). C'est sans doute le bouquin qui m'a fait faire
le plus de progres en qualite de code OO.
Ca, et d'aller fureter un peu dans une implementation smalltalk decente,
squeak, pour ne pas la citer...
In article <48bc0673$0$949$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Peu de monde maîtrise réellement l'OO de toute façon, hélas...
Je conseille tres fortement le bouquin
_Refactoring: improving the design of existing code_, de Martin Fowler
(ISBN 0-201-48567-2). C'est sans doute le bouquin qui m'a fait faire
le plus de progres en qualite de code OO.
Ca, et d'aller fureter un peu dans une implementation smalltalk decente,
squeak, pour ne pas la citer...
In article <48bc0673$0$949$,
Wykaaa wrote:Peu de monde maîtrise réellement l'OO de toute façon, hélas...
Je conseille tres fortement le bouquin
_Refactoring: improving the design of existing code_, de Martin Fowler
(ISBN 0-201-48567-2). C'est sans doute le bouquin qui m'a fait faire
le plus de progres en qualite de code OO.
Ca, et d'aller fureter un peu dans une implementation smalltalk decente,
squeak, pour ne pas la citer...
Francois a écrit :
Tiens, en tapant "Conception et programmation orientée objet" sur
google, je tombe sur ce cours : http://rainet.enic.fr/unit/A43/index.htm
Ça a l'air vachement bien. :-)
Je trouve ce lien très intéressant et l'auteur fait un bel effort de
vulgarisation, dommage que tout soit dans des frames.
Alors, dans sa séquence 1, l'auteur attribue le développement des
langages OO à la "crise du logiciel" (qui proviendrait de sa
complexification croissante) et justement dans la 4ème page du menu
"crise du logiciel", il cite des projets d'ampleurs croissantes (j'ai
pas compris ses unités hommes/ mois) :
Compilateur (C, Pascal...) -> 120 HM
Compilateur ADA -> 1800 HM
Logiciel Navette -> 12000 HM
Système d'exploitation -> 60000 HM
Bon, justement, un des logiciels les plus complexes est un OS. Or, des
OS comme Linux ou Windows pour x86 sont en général écrit majoritairement
en C avec de l'assembleur dans de petites proportions.
Donc, ma question est : pourquoi ne réécrit-on from scratch pas les OS
dans un langage objet genre C++ ? Trop de travail ? pas utile ?
Autre question dans le même registre : comment se fait-il que les
implémentations de langage objets comme Python et Ruby soient écrits en
C et non pas en C++ ? Pour Python 3000, il semblerait qu'il avait été
envisagé de tout réécrire, cf.
http://python.org/dev/peps/pep-3000/
Et les jvm, elles sont écrites en C ou en C++ ? Un compilateur C++ est
écrit en quoi ? Sinon, il me semble que le compilateur DMD est écrit en C.
Francois a écrit :
Tiens, en tapant "Conception et programmation orientée objet" sur
google, je tombe sur ce cours : http://rainet.enic.fr/unit/A43/index.htm
Ça a l'air vachement bien. :-)
Je trouve ce lien très intéressant et l'auteur fait un bel effort de
vulgarisation, dommage que tout soit dans des frames.
Alors, dans sa séquence 1, l'auteur attribue le développement des
langages OO à la "crise du logiciel" (qui proviendrait de sa
complexification croissante) et justement dans la 4ème page du menu
"crise du logiciel", il cite des projets d'ampleurs croissantes (j'ai
pas compris ses unités hommes/ mois) :
Compilateur (C, Pascal...) -> 120 HM
Compilateur ADA -> 1800 HM
Logiciel Navette -> 12000 HM
Système d'exploitation -> 60000 HM
Bon, justement, un des logiciels les plus complexes est un OS. Or, des
OS comme Linux ou Windows pour x86 sont en général écrit majoritairement
en C avec de l'assembleur dans de petites proportions.
Donc, ma question est : pourquoi ne réécrit-on from scratch pas les OS
dans un langage objet genre C++ ? Trop de travail ? pas utile ?
Autre question dans le même registre : comment se fait-il que les
implémentations de langage objets comme Python et Ruby soient écrits en
C et non pas en C++ ? Pour Python 3000, il semblerait qu'il avait été
envisagé de tout réécrire, cf.
http://python.org/dev/peps/pep-3000/
Et les jvm, elles sont écrites en C ou en C++ ? Un compilateur C++ est
écrit en quoi ? Sinon, il me semble que le compilateur DMD est écrit en C.
Francois a écrit :
Tiens, en tapant "Conception et programmation orientée objet" sur
google, je tombe sur ce cours : http://rainet.enic.fr/unit/A43/index.htm
Ça a l'air vachement bien. :-)
Je trouve ce lien très intéressant et l'auteur fait un bel effort de
vulgarisation, dommage que tout soit dans des frames.
Alors, dans sa séquence 1, l'auteur attribue le développement des
langages OO à la "crise du logiciel" (qui proviendrait de sa
complexification croissante) et justement dans la 4ème page du menu
"crise du logiciel", il cite des projets d'ampleurs croissantes (j'ai
pas compris ses unités hommes/ mois) :
Compilateur (C, Pascal...) -> 120 HM
Compilateur ADA -> 1800 HM
Logiciel Navette -> 12000 HM
Système d'exploitation -> 60000 HM
Bon, justement, un des logiciels les plus complexes est un OS. Or, des
OS comme Linux ou Windows pour x86 sont en général écrit majoritairement
en C avec de l'assembleur dans de petites proportions.
Donc, ma question est : pourquoi ne réécrit-on from scratch pas les OS
dans un langage objet genre C++ ? Trop de travail ? pas utile ?
Autre question dans le même registre : comment se fait-il que les
implémentations de langage objets comme Python et Ruby soient écrits en
C et non pas en C++ ? Pour Python 3000, il semblerait qu'il avait été
envisagé de tout réécrire, cf.
http://python.org/dev/peps/pep-3000/
Et les jvm, elles sont écrites en C ou en C++ ? Un compilateur C++ est
écrit en quoi ? Sinon, il me semble que le compilateur DMD est écrit en C.
Antoine Leca a écrit :En news:48ba96bf$0$961$, Wykaaa va escriure:Donc, pour résumer, l'approche objet s'appuie sur 4 concepts majeurs
de base :
- le concept d'abstraction (se matérialise par la notion de classe
dans un langage de programmation objet)
- le concept d'encapsulation qui permet à un objet (une classe donc)
de ne montrer à l'extérieur que ce qui est nécessaire à son
utilisation. Ce concept est matérialisé dans les LOO (langages
orientés objet) par les directives de contrôle d'accès (private,
protected, public)
- le concept de modularité (au sens objet) qui s'ppuie sur 2
principes :
- La forte cohésion : un objet ne traite que d'une seule
abstraction et il la traite entièrement
- Le faible couplage : minimisation des dépendances entre
classes et encapsulation
ATTENTION : cette notion de modularité est piégeuse car dans les
langages on a aussi la notion de package (regroupement de plusieurs
classes). Le faible couplage est souvent mis en oeuvre, dans les
grosses applications, au niveau des packages et non au niveau des
classes car la granularité est trop fine.
- Enfin le concept de hiérarchie. Il est mis en oeuvre, dans les
LOO, à travers l'héritage mais aussi à travers la
composition/agrégation d'objets.
Si on revient à C, le concept d'encapsulation est me semble-t-il
traité par la séparation .h/.c et des règles de gestion, et le
concept de modularité par d'autres règles de gestion, mais le
langage n'est aucunement un obstacle.
C'est la modularité qui est traitée par la séparation .h/.c.
Ensuite, tout dépend de ce que tu mets dans le .h.
Pour respecter le concept d'encapsulation, le .h présentera uniquement
un pointeur sur la structure [...]
un moyen d'accès aux pointeurs sur
fonctions qui représentent les "méthodes" de l'abstraction
(Il faut que le programmeur puisse les appeler. C'est un moyen de
rendre les fonctions "publiques").
Le concept d'héritage est (toujours « me semble-t-il »)
spécifiquement mis en ouvre par les règles relatives aux pointeurs
de structure et d'union.
Pour l'héritage, on peut faire comme tu dis ou mettre en place tout un
mécanisme à base de macros du préprocesseur (ce qui était fait pour
X-Window/Motif).
Le plus difficile est de simuler le polymorphisme car il faut tout
faire "à la main" (se le programmer...).
Le concept d'abstraction tel que décrit ci-dessus n'a aucun sens
pour moi. Se reférerait-il à l'utilisation de pointeurs ?
En C, une abstraction sera représentée par une structure qui contient
les attributs de l'abstraction (les champs de données) et les
pointeurs sur les fonctions qui permettent de manipuler ces champs
de données (l'équivalent des méthodes dans une classe "à la C++")
Si j'ai bien compris, on peut faire ce genre d'approche orientée
objets avec le langage C plus quelques règles (communément
observées) sur ce qui s'appelle traditionellement en C la
compilation séparée, c'est-à-dire le découpage en module ?
Absolument. c'est ce que j'ai essayé de décrire ci-dessus
Antoine Leca a écrit :
En news:48ba96bf$0$961$ba4acef3@news.orange.fr, Wykaaa va escriure:
Donc, pour résumer, l'approche objet s'appuie sur 4 concepts majeurs
de base :
- le concept d'abstraction (se matérialise par la notion de classe
dans un langage de programmation objet)
- le concept d'encapsulation qui permet à un objet (une classe donc)
de ne montrer à l'extérieur que ce qui est nécessaire à son
utilisation. Ce concept est matérialisé dans les LOO (langages
orientés objet) par les directives de contrôle d'accès (private,
protected, public)
- le concept de modularité (au sens objet) qui s'ppuie sur 2
principes :
- La forte cohésion : un objet ne traite que d'une seule
abstraction et il la traite entièrement
- Le faible couplage : minimisation des dépendances entre
classes et encapsulation
ATTENTION : cette notion de modularité est piégeuse car dans les
langages on a aussi la notion de package (regroupement de plusieurs
classes). Le faible couplage est souvent mis en oeuvre, dans les
grosses applications, au niveau des packages et non au niveau des
classes car la granularité est trop fine.
- Enfin le concept de hiérarchie. Il est mis en oeuvre, dans les
LOO, à travers l'héritage mais aussi à travers la
composition/agrégation d'objets.
Si on revient à C, le concept d'encapsulation est me semble-t-il
traité par la séparation .h/.c et des règles de gestion, et le
concept de modularité par d'autres règles de gestion, mais le
langage n'est aucunement un obstacle.
C'est la modularité qui est traitée par la séparation .h/.c.
Ensuite, tout dépend de ce que tu mets dans le .h.
Pour respecter le concept d'encapsulation, le .h présentera uniquement
un pointeur sur la structure [...]
un moyen d'accès aux pointeurs sur
fonctions qui représentent les "méthodes" de l'abstraction
(Il faut que le programmeur puisse les appeler. C'est un moyen de
rendre les fonctions "publiques").
Le concept d'héritage est (toujours « me semble-t-il »)
spécifiquement mis en ouvre par les règles relatives aux pointeurs
de structure et d'union.
Pour l'héritage, on peut faire comme tu dis ou mettre en place tout un
mécanisme à base de macros du préprocesseur (ce qui était fait pour
X-Window/Motif).
Le plus difficile est de simuler le polymorphisme car il faut tout
faire "à la main" (se le programmer...).
Le concept d'abstraction tel que décrit ci-dessus n'a aucun sens
pour moi. Se reférerait-il à l'utilisation de pointeurs ?
En C, une abstraction sera représentée par une structure qui contient
les attributs de l'abstraction (les champs de données) et les
pointeurs sur les fonctions qui permettent de manipuler ces champs
de données (l'équivalent des méthodes dans une classe "à la C++")
Si j'ai bien compris, on peut faire ce genre d'approche orientée
objets avec le langage C plus quelques règles (communément
observées) sur ce qui s'appelle traditionellement en C la
compilation séparée, c'est-à-dire le découpage en module ?
Absolument. c'est ce que j'ai essayé de décrire ci-dessus
Antoine Leca a écrit :En news:48ba96bf$0$961$, Wykaaa va escriure:Donc, pour résumer, l'approche objet s'appuie sur 4 concepts majeurs
de base :
- le concept d'abstraction (se matérialise par la notion de classe
dans un langage de programmation objet)
- le concept d'encapsulation qui permet à un objet (une classe donc)
de ne montrer à l'extérieur que ce qui est nécessaire à son
utilisation. Ce concept est matérialisé dans les LOO (langages
orientés objet) par les directives de contrôle d'accès (private,
protected, public)
- le concept de modularité (au sens objet) qui s'ppuie sur 2
principes :
- La forte cohésion : un objet ne traite que d'une seule
abstraction et il la traite entièrement
- Le faible couplage : minimisation des dépendances entre
classes et encapsulation
ATTENTION : cette notion de modularité est piégeuse car dans les
langages on a aussi la notion de package (regroupement de plusieurs
classes). Le faible couplage est souvent mis en oeuvre, dans les
grosses applications, au niveau des packages et non au niveau des
classes car la granularité est trop fine.
- Enfin le concept de hiérarchie. Il est mis en oeuvre, dans les
LOO, à travers l'héritage mais aussi à travers la
composition/agrégation d'objets.
Si on revient à C, le concept d'encapsulation est me semble-t-il
traité par la séparation .h/.c et des règles de gestion, et le
concept de modularité par d'autres règles de gestion, mais le
langage n'est aucunement un obstacle.
C'est la modularité qui est traitée par la séparation .h/.c.
Ensuite, tout dépend de ce que tu mets dans le .h.
Pour respecter le concept d'encapsulation, le .h présentera uniquement
un pointeur sur la structure [...]
un moyen d'accès aux pointeurs sur
fonctions qui représentent les "méthodes" de l'abstraction
(Il faut que le programmeur puisse les appeler. C'est un moyen de
rendre les fonctions "publiques").
Le concept d'héritage est (toujours « me semble-t-il »)
spécifiquement mis en ouvre par les règles relatives aux pointeurs
de structure et d'union.
Pour l'héritage, on peut faire comme tu dis ou mettre en place tout un
mécanisme à base de macros du préprocesseur (ce qui était fait pour
X-Window/Motif).
Le plus difficile est de simuler le polymorphisme car il faut tout
faire "à la main" (se le programmer...).
Le concept d'abstraction tel que décrit ci-dessus n'a aucun sens
pour moi. Se reférerait-il à l'utilisation de pointeurs ?
En C, une abstraction sera représentée par une structure qui contient
les attributs de l'abstraction (les champs de données) et les
pointeurs sur les fonctions qui permettent de manipuler ces champs
de données (l'équivalent des méthodes dans une classe "à la C++")
Si j'ai bien compris, on peut faire ce genre d'approche orientée
objets avec le langage C plus quelques règles (communément
observées) sur ce qui s'appelle traditionellement en C la
compilation séparée, c'est-à-dire le découpage en module ?
Absolument. c'est ce que j'ai essayé de décrire ci-dessus
En news:48bbe7f6$0$857$, Wykaaa va escriure:Antoine Leca a écrit :En news:48ba96bf$0$961$, Wykaaa va escriure:Donc, pour résumer, l'approche objet s'appuie sur 4 concepts majeurs
de base :
- le concept d'abstraction (se matérialise par la notion de classe
dans un langage de programmation objet)
- le concept d'encapsulation qui permet à un objet (une classe donc)
de ne montrer à l'extérieur que ce qui est nécessaire à son
utilisation. Ce concept est matérialisé dans les LOO (langages
orientés objet) par les directives de contrôle d'accès (private,
protected, public)
- le concept de modularité (au sens objet) qui s'ppuie sur 2
principes :
- La forte cohésion : un objet ne traite que d'une seule
abstraction et il la traite entièrement
- Le faible couplage : minimisation des dépendances entre
classes et encapsulation
ATTENTION : cette notion de modularité est piégeuse car dans les
langages on a aussi la notion de package (regroupement de plusieurs
classes). Le faible couplage est souvent mis en oeuvre, dans les
grosses applications, au niveau des packages et non au niveau des
classes car la granularité est trop fine.
- Enfin le concept de hiérarchie. Il est mis en oeuvre, dans les
LOO, à travers l'héritage mais aussi à travers la
composition/agrégation d'objets.
Si on revient à C, le concept d'encapsulation est me semble-t-il
traité par la séparation .h/.c et des règles de gestion, et le
concept de modularité par d'autres règles de gestion, mais le
langage n'est aucunement un obstacle.
C'est la modularité qui est traitée par la séparation .h/.c.
Ensuite, tout dépend de ce que tu mets dans le .h.
En fait, cela dépend surtout des règles de gestion que tu [t'] imposes.
Si tu imposes comme règle de gestion : n'utiliser des « objets » que ce qui
est documenté, pas ce qui est écrit dans le .h --c'est la règle retenue pour
le « C portable » promu par la norme-- tu obtiens un certain niveau.
Si par contre tu dis « la documentation ultime est le source », tu obtiens
un autre niveau.
Quant à savoir si ces règles sont des niveaux d'abstraction, d'encapsulation
ou de modularité, c'était ma question.Pour respecter le concept d'encapsulation, le .h présentera uniquement
un pointeur sur la structure [...]
Ah OK, je me suis mal exprimé.
Toi tu fais allusion au .h externe, celui qui est #inclus par les
consomateurs de l'objet (.h que tu vois unique par objet).
Personnellement, je faisais référence aux véritables .h situés au même
niveau que les .c, avec la vraie structure des « objets ».
Le préprocesseur C tel que normalisé a d'ailleurs un mécanisme prêt pour
cela, les #include avec <totatu.h> ou "objet_toto.h".
Par ailleurs, une telle organisation facilite ÀMHA énormément
l'implémentation de l'héritage (simple).
[ Pour respecter le concept d'encapsulation, le .h présentera uniquement
...]un moyen d'accès aux pointeurs sur
fonctions qui représentent les "méthodes" de l'abstraction
Nous y voilà : tu as introduit ces fameux pointeurs vers fonction.
Mais pourquoi les méthodes doivent-elles être des pointeurs vers fonction ?
C'est bien beau d'encapsuler, mais pourquoi rajouter un niveau
d'indirection, par ailleurs tellement coûteux que certaines implémentations
permettent explicitement de le contourner ? voire comme C++ le font par
défaut ?
(Il faut que le programmeur puisse les appeler. C'est un moyen de
rendre les fonctions "publiques").
On peut aussi appeler des fonctions tout court, le fait que ce soit des
pointeurs me paraît être du sucre théorique, si tu vois ce que je veux dire.
Pour en revenir à l'encapsulation telle que définie ci-dessus, les marqueurs
public/protected/private de C++ permettent effectivement (et jusqu'à un
certain point) de diriger l'encapsulation, mais je crois qu'à ce niveau il y
a un équilibre à trouver, équilibre qui peut changer en fonction de la
maturité du projet : et je ne vois pas cet aspect dynamique dans les
concepts ci-dessus.
Le concept d'héritage est (toujours « me semble-t-il »)
spécifiquement mis en ouvre par les règles relatives aux pointeurs
de structure et d'union.
Pour l'héritage, on peut faire comme tu dis ou mettre en place tout un
mécanisme à base de macros du préprocesseur (ce qui était fait pour
X-Window/Motif).
Qui je suppose va finir par utiliser la même règle sous-jacente de
« commutatibilité » des structures...
De toutes manières, en C, quand on définit une union, on se retrouve le plus
souvent à mettre en place des macros du préprocesseur, au moins pour cacher
les traînées de sélecteurs sans signification...
Le plus difficile est de simuler le polymorphisme car il faut tout
faire "à la main" (se le programmer...).
Euh, il faut aussi de l'héritage polymorphique pour avoir une « vraie »
approche objet ? Là encore, quel est le concept qui veut cela ? (ne me dis
pas hiérarchie, parce que pour moi, hiérarchie signifie exactement le
contraire de ce que permet l'héritage polymorphique...)
Tu n'es pas en train « d'étirer » un peu le modèle, là ?
Le concept d'abstraction tel que décrit ci-dessus n'a aucun sens
pour moi. Se reférerait-il à l'utilisation de pointeurs ?
En C, une abstraction sera représentée par une structure qui contient
les attributs de l'abstraction (les champs de données) et les
pointeurs sur les fonctions qui permettent de manipuler ces champs
de données (l'équivalent des méthodes dans une classe "à la C++")
Si je comprend bien, le concept d'abstraction consiste à regrouper les «
attributs » et les « méthodes » permettant de les manipuler, c'est bien cela
?
Donc en C, on va effectivement utiliser des structures (ce que j'avais
sous-entendu dès le début).
Pour ce qui est des méthodes, le plus courant en C est d'utiliser des règles
de nommage.
Maintenant, je ne comprends pas la démonstration de la nécessité de ranger
toutes les méthodes comme des pointeurs vers fonctions logées dans chaque
instance des objets manipulés ; d'ailleurs je pense que la plupart des
implémentations de C++ ne font pas cela, et utilisent un niveau
supplémentaire comme par exemple une table de méthodes virtuelles ; d'autres
ont des informations dynamiques de type qui jouent un rôle similaire.
Si j'ai bien compris, on peut faire ce genre d'approche orientée
objets avec le langage C plus quelques règles (communément
observées) sur ce qui s'appelle traditionellement en C la
compilation séparée, c'est-à-dire le découpage en module ?
Absolument. c'est ce que j'ai essayé de décrire ci-dessus
Et, pour autant que j'ai bien suivi, pour peu que l'on ait des structures,
des pointeurs (même les /access/ d'Ada83 devraient suffire), un mécanisme de
compilation séparée et la possibilité de définir quelques règles de gestion,
on doit pouvoir le faire avec beaucoup de L3G, non ?
(OK, on s'accorde généralement à considérer qu'il faut aussi des pointeurs
vers fonctions mais je n'ai toujours pas compris pourquoi.)
Donc, si tu peux utiliser un langage qui n'est *pas* « orienté objet » pour
utiliser « l'approche objet », cela signifie que les deux concepts ne sont
pas sur le même plan, n'est-ce pas ?
Le vrai problème, c'est qu'il devient alors facile de rendre complètement
floue la définition de « l'approche objet » (d'où les inutiles querelles de
clochers déjà mentionnées, et même vues récemment), à partir du moment où on
perd la relation supposée existente entre cette approche et les langages
(dits) orientés objet.
À ce s'ajoute bien sûr que ces dits langages n'oblige que très
exceptionnellement à se contraindre strictement à cette approche, à la fois
pour des raisons pratiques (le faire de contrainte le style des programmeurs
de manière trop catégorique serait s'interdire d'entrée la possibilité de
succès)
/pouvoir/ capitaliser sur l'existant des programmes et autres bibliothèques
non-orientés objet).
Résultat, tu te retrouves avec des références de 1200 pages, où tu peux
certainement trouver à boire et à manger.
Je comprends tout-à-fait les interrogations de François...
En news:48bbe7f6$0$857$ba4acef3@news.orange.fr, Wykaaa va escriure:
Antoine Leca a écrit :
En news:48ba96bf$0$961$ba4acef3@news.orange.fr, Wykaaa va escriure:
Donc, pour résumer, l'approche objet s'appuie sur 4 concepts majeurs
de base :
- le concept d'abstraction (se matérialise par la notion de classe
dans un langage de programmation objet)
- le concept d'encapsulation qui permet à un objet (une classe donc)
de ne montrer à l'extérieur que ce qui est nécessaire à son
utilisation. Ce concept est matérialisé dans les LOO (langages
orientés objet) par les directives de contrôle d'accès (private,
protected, public)
- le concept de modularité (au sens objet) qui s'ppuie sur 2
principes :
- La forte cohésion : un objet ne traite que d'une seule
abstraction et il la traite entièrement
- Le faible couplage : minimisation des dépendances entre
classes et encapsulation
ATTENTION : cette notion de modularité est piégeuse car dans les
langages on a aussi la notion de package (regroupement de plusieurs
classes). Le faible couplage est souvent mis en oeuvre, dans les
grosses applications, au niveau des packages et non au niveau des
classes car la granularité est trop fine.
- Enfin le concept de hiérarchie. Il est mis en oeuvre, dans les
LOO, à travers l'héritage mais aussi à travers la
composition/agrégation d'objets.
Si on revient à C, le concept d'encapsulation est me semble-t-il
traité par la séparation .h/.c et des règles de gestion, et le
concept de modularité par d'autres règles de gestion, mais le
langage n'est aucunement un obstacle.
C'est la modularité qui est traitée par la séparation .h/.c.
Ensuite, tout dépend de ce que tu mets dans le .h.
En fait, cela dépend surtout des règles de gestion que tu [t'] imposes.
Si tu imposes comme règle de gestion : n'utiliser des « objets » que ce qui
est documenté, pas ce qui est écrit dans le .h --c'est la règle retenue pour
le « C portable » promu par la norme-- tu obtiens un certain niveau.
Si par contre tu dis « la documentation ultime est le source », tu obtiens
un autre niveau.
Quant à savoir si ces règles sont des niveaux d'abstraction, d'encapsulation
ou de modularité, c'était ma question.
Pour respecter le concept d'encapsulation, le .h présentera uniquement
un pointeur sur la structure [...]
Ah OK, je me suis mal exprimé.
Toi tu fais allusion au .h externe, celui qui est #inclus par les
consomateurs de l'objet (.h que tu vois unique par objet).
Personnellement, je faisais référence aux véritables .h situés au même
niveau que les .c, avec la vraie structure des « objets ».
Le préprocesseur C tel que normalisé a d'ailleurs un mécanisme prêt pour
cela, les #include avec <totatu.h> ou "objet_toto.h".
Par ailleurs, une telle organisation facilite ÀMHA énormément
l'implémentation de l'héritage (simple).
[ Pour respecter le concept d'encapsulation, le .h présentera uniquement
...]
un moyen d'accès aux pointeurs sur
fonctions qui représentent les "méthodes" de l'abstraction
Nous y voilà : tu as introduit ces fameux pointeurs vers fonction.
Mais pourquoi les méthodes doivent-elles être des pointeurs vers fonction ?
C'est bien beau d'encapsuler, mais pourquoi rajouter un niveau
d'indirection, par ailleurs tellement coûteux que certaines implémentations
permettent explicitement de le contourner ? voire comme C++ le font par
défaut ?
(Il faut que le programmeur puisse les appeler. C'est un moyen de
rendre les fonctions "publiques").
On peut aussi appeler des fonctions tout court, le fait que ce soit des
pointeurs me paraît être du sucre théorique, si tu vois ce que je veux dire.
Pour en revenir à l'encapsulation telle que définie ci-dessus, les marqueurs
public/protected/private de C++ permettent effectivement (et jusqu'à un
certain point) de diriger l'encapsulation, mais je crois qu'à ce niveau il y
a un équilibre à trouver, équilibre qui peut changer en fonction de la
maturité du projet : et je ne vois pas cet aspect dynamique dans les
concepts ci-dessus.
Le concept d'héritage est (toujours « me semble-t-il »)
spécifiquement mis en ouvre par les règles relatives aux pointeurs
de structure et d'union.
Pour l'héritage, on peut faire comme tu dis ou mettre en place tout un
mécanisme à base de macros du préprocesseur (ce qui était fait pour
X-Window/Motif).
Qui je suppose va finir par utiliser la même règle sous-jacente de
« commutatibilité » des structures...
De toutes manières, en C, quand on définit une union, on se retrouve le plus
souvent à mettre en place des macros du préprocesseur, au moins pour cacher
les traînées de sélecteurs sans signification...
Le plus difficile est de simuler le polymorphisme car il faut tout
faire "à la main" (se le programmer...).
Euh, il faut aussi de l'héritage polymorphique pour avoir une « vraie »
approche objet ? Là encore, quel est le concept qui veut cela ? (ne me dis
pas hiérarchie, parce que pour moi, hiérarchie signifie exactement le
contraire de ce que permet l'héritage polymorphique...)
Tu n'es pas en train « d'étirer » un peu le modèle, là ?
Le concept d'abstraction tel que décrit ci-dessus n'a aucun sens
pour moi. Se reférerait-il à l'utilisation de pointeurs ?
En C, une abstraction sera représentée par une structure qui contient
les attributs de l'abstraction (les champs de données) et les
pointeurs sur les fonctions qui permettent de manipuler ces champs
de données (l'équivalent des méthodes dans une classe "à la C++")
Si je comprend bien, le concept d'abstraction consiste à regrouper les «
attributs » et les « méthodes » permettant de les manipuler, c'est bien cela
?
Donc en C, on va effectivement utiliser des structures (ce que j'avais
sous-entendu dès le début).
Pour ce qui est des méthodes, le plus courant en C est d'utiliser des règles
de nommage.
Maintenant, je ne comprends pas la démonstration de la nécessité de ranger
toutes les méthodes comme des pointeurs vers fonctions logées dans chaque
instance des objets manipulés ; d'ailleurs je pense que la plupart des
implémentations de C++ ne font pas cela, et utilisent un niveau
supplémentaire comme par exemple une table de méthodes virtuelles ; d'autres
ont des informations dynamiques de type qui jouent un rôle similaire.
Si j'ai bien compris, on peut faire ce genre d'approche orientée
objets avec le langage C plus quelques règles (communément
observées) sur ce qui s'appelle traditionellement en C la
compilation séparée, c'est-à-dire le découpage en module ?
Absolument. c'est ce que j'ai essayé de décrire ci-dessus
Et, pour autant que j'ai bien suivi, pour peu que l'on ait des structures,
des pointeurs (même les /access/ d'Ada83 devraient suffire), un mécanisme de
compilation séparée et la possibilité de définir quelques règles de gestion,
on doit pouvoir le faire avec beaucoup de L3G, non ?
(OK, on s'accorde généralement à considérer qu'il faut aussi des pointeurs
vers fonctions mais je n'ai toujours pas compris pourquoi.)
Donc, si tu peux utiliser un langage qui n'est *pas* « orienté objet » pour
utiliser « l'approche objet », cela signifie que les deux concepts ne sont
pas sur le même plan, n'est-ce pas ?
Le vrai problème, c'est qu'il devient alors facile de rendre complètement
floue la définition de « l'approche objet » (d'où les inutiles querelles de
clochers déjà mentionnées, et même vues récemment), à partir du moment où on
perd la relation supposée existente entre cette approche et les langages
(dits) orientés objet.
À ce s'ajoute bien sûr que ces dits langages n'oblige que très
exceptionnellement à se contraindre strictement à cette approche, à la fois
pour des raisons pratiques (le faire de contrainte le style des programmeurs
de manière trop catégorique serait s'interdire d'entrée la possibilité de
succès)
/pouvoir/ capitaliser sur l'existant des programmes et autres bibliothèques
non-orientés objet).
Résultat, tu te retrouves avec des références de 1200 pages, où tu peux
certainement trouver à boire et à manger.
Je comprends tout-à-fait les interrogations de François...
En news:48bbe7f6$0$857$, Wykaaa va escriure:Antoine Leca a écrit :En news:48ba96bf$0$961$, Wykaaa va escriure:Donc, pour résumer, l'approche objet s'appuie sur 4 concepts majeurs
de base :
- le concept d'abstraction (se matérialise par la notion de classe
dans un langage de programmation objet)
- le concept d'encapsulation qui permet à un objet (une classe donc)
de ne montrer à l'extérieur que ce qui est nécessaire à son
utilisation. Ce concept est matérialisé dans les LOO (langages
orientés objet) par les directives de contrôle d'accès (private,
protected, public)
- le concept de modularité (au sens objet) qui s'ppuie sur 2
principes :
- La forte cohésion : un objet ne traite que d'une seule
abstraction et il la traite entièrement
- Le faible couplage : minimisation des dépendances entre
classes et encapsulation
ATTENTION : cette notion de modularité est piégeuse car dans les
langages on a aussi la notion de package (regroupement de plusieurs
classes). Le faible couplage est souvent mis en oeuvre, dans les
grosses applications, au niveau des packages et non au niveau des
classes car la granularité est trop fine.
- Enfin le concept de hiérarchie. Il est mis en oeuvre, dans les
LOO, à travers l'héritage mais aussi à travers la
composition/agrégation d'objets.
Si on revient à C, le concept d'encapsulation est me semble-t-il
traité par la séparation .h/.c et des règles de gestion, et le
concept de modularité par d'autres règles de gestion, mais le
langage n'est aucunement un obstacle.
C'est la modularité qui est traitée par la séparation .h/.c.
Ensuite, tout dépend de ce que tu mets dans le .h.
En fait, cela dépend surtout des règles de gestion que tu [t'] imposes.
Si tu imposes comme règle de gestion : n'utiliser des « objets » que ce qui
est documenté, pas ce qui est écrit dans le .h --c'est la règle retenue pour
le « C portable » promu par la norme-- tu obtiens un certain niveau.
Si par contre tu dis « la documentation ultime est le source », tu obtiens
un autre niveau.
Quant à savoir si ces règles sont des niveaux d'abstraction, d'encapsulation
ou de modularité, c'était ma question.Pour respecter le concept d'encapsulation, le .h présentera uniquement
un pointeur sur la structure [...]
Ah OK, je me suis mal exprimé.
Toi tu fais allusion au .h externe, celui qui est #inclus par les
consomateurs de l'objet (.h que tu vois unique par objet).
Personnellement, je faisais référence aux véritables .h situés au même
niveau que les .c, avec la vraie structure des « objets ».
Le préprocesseur C tel que normalisé a d'ailleurs un mécanisme prêt pour
cela, les #include avec <totatu.h> ou "objet_toto.h".
Par ailleurs, une telle organisation facilite ÀMHA énormément
l'implémentation de l'héritage (simple).
[ Pour respecter le concept d'encapsulation, le .h présentera uniquement
...]un moyen d'accès aux pointeurs sur
fonctions qui représentent les "méthodes" de l'abstraction
Nous y voilà : tu as introduit ces fameux pointeurs vers fonction.
Mais pourquoi les méthodes doivent-elles être des pointeurs vers fonction ?
C'est bien beau d'encapsuler, mais pourquoi rajouter un niveau
d'indirection, par ailleurs tellement coûteux que certaines implémentations
permettent explicitement de le contourner ? voire comme C++ le font par
défaut ?
(Il faut que le programmeur puisse les appeler. C'est un moyen de
rendre les fonctions "publiques").
On peut aussi appeler des fonctions tout court, le fait que ce soit des
pointeurs me paraît être du sucre théorique, si tu vois ce que je veux dire.
Pour en revenir à l'encapsulation telle que définie ci-dessus, les marqueurs
public/protected/private de C++ permettent effectivement (et jusqu'à un
certain point) de diriger l'encapsulation, mais je crois qu'à ce niveau il y
a un équilibre à trouver, équilibre qui peut changer en fonction de la
maturité du projet : et je ne vois pas cet aspect dynamique dans les
concepts ci-dessus.
Le concept d'héritage est (toujours « me semble-t-il »)
spécifiquement mis en ouvre par les règles relatives aux pointeurs
de structure et d'union.
Pour l'héritage, on peut faire comme tu dis ou mettre en place tout un
mécanisme à base de macros du préprocesseur (ce qui était fait pour
X-Window/Motif).
Qui je suppose va finir par utiliser la même règle sous-jacente de
« commutatibilité » des structures...
De toutes manières, en C, quand on définit une union, on se retrouve le plus
souvent à mettre en place des macros du préprocesseur, au moins pour cacher
les traînées de sélecteurs sans signification...
Le plus difficile est de simuler le polymorphisme car il faut tout
faire "à la main" (se le programmer...).
Euh, il faut aussi de l'héritage polymorphique pour avoir une « vraie »
approche objet ? Là encore, quel est le concept qui veut cela ? (ne me dis
pas hiérarchie, parce que pour moi, hiérarchie signifie exactement le
contraire de ce que permet l'héritage polymorphique...)
Tu n'es pas en train « d'étirer » un peu le modèle, là ?
Le concept d'abstraction tel que décrit ci-dessus n'a aucun sens
pour moi. Se reférerait-il à l'utilisation de pointeurs ?
En C, une abstraction sera représentée par une structure qui contient
les attributs de l'abstraction (les champs de données) et les
pointeurs sur les fonctions qui permettent de manipuler ces champs
de données (l'équivalent des méthodes dans une classe "à la C++")
Si je comprend bien, le concept d'abstraction consiste à regrouper les «
attributs » et les « méthodes » permettant de les manipuler, c'est bien cela
?
Donc en C, on va effectivement utiliser des structures (ce que j'avais
sous-entendu dès le début).
Pour ce qui est des méthodes, le plus courant en C est d'utiliser des règles
de nommage.
Maintenant, je ne comprends pas la démonstration de la nécessité de ranger
toutes les méthodes comme des pointeurs vers fonctions logées dans chaque
instance des objets manipulés ; d'ailleurs je pense que la plupart des
implémentations de C++ ne font pas cela, et utilisent un niveau
supplémentaire comme par exemple une table de méthodes virtuelles ; d'autres
ont des informations dynamiques de type qui jouent un rôle similaire.
Si j'ai bien compris, on peut faire ce genre d'approche orientée
objets avec le langage C plus quelques règles (communément
observées) sur ce qui s'appelle traditionellement en C la
compilation séparée, c'est-à-dire le découpage en module ?
Absolument. c'est ce que j'ai essayé de décrire ci-dessus
Et, pour autant que j'ai bien suivi, pour peu que l'on ait des structures,
des pointeurs (même les /access/ d'Ada83 devraient suffire), un mécanisme de
compilation séparée et la possibilité de définir quelques règles de gestion,
on doit pouvoir le faire avec beaucoup de L3G, non ?
(OK, on s'accorde généralement à considérer qu'il faut aussi des pointeurs
vers fonctions mais je n'ai toujours pas compris pourquoi.)
Donc, si tu peux utiliser un langage qui n'est *pas* « orienté objet » pour
utiliser « l'approche objet », cela signifie que les deux concepts ne sont
pas sur le même plan, n'est-ce pas ?
Le vrai problème, c'est qu'il devient alors facile de rendre complètement
floue la définition de « l'approche objet » (d'où les inutiles querelles de
clochers déjà mentionnées, et même vues récemment), à partir du moment où on
perd la relation supposée existente entre cette approche et les langages
(dits) orientés objet.
À ce s'ajoute bien sûr que ces dits langages n'oblige que très
exceptionnellement à se contraindre strictement à cette approche, à la fois
pour des raisons pratiques (le faire de contrainte le style des programmeurs
de manière trop catégorique serait s'interdire d'entrée la possibilité de
succès)
/pouvoir/ capitaliser sur l'existant des programmes et autres bibliothèques
non-orientés objet).
Résultat, tu te retrouves avec des références de 1200 pages, où tu peux
certainement trouver à boire et à manger.
Je comprends tout-à-fait les interrogations de François...