On Wed, Jun 26, 2002 at 11:30:37AM +0200, Yves Martin wrote:
> En réponse à Miguel Moquillon <miguel.moquillon@???>:
>
> En ce qui me concerne la définition formel du type énuméré
> m'importe peu tant que l'implémentation choisie en a l'usage.
> Et c'est le cas pour la classe que je propose.
Les definitions formelles de ce que tu manipules devrait t'interesse bcp
plus que ca, independemment de l'implementation.
D'une part parce que la reponse a certain pb sont dedans. D'autre part
parce que ca evite a ecrire des choses qui sont fausses du point de vue
modelisation.
En Objet, si jamais tu ecris quelque chose de bancale, ca pardonne plus
... ca devient tout sauf de l'objet et c'est pas parce que tu as des
classes que tu fais de l'objet.
De plus, dans ton exemple, on doit ecrire une classe par type enumere
que l'on desire : trop lourd en plus d'etre bancale du point de vue
objet.
> > C'est vrai, parce que ne sont que des entiers finalement, le
> > developeur s'il veut faire crade, il peut en faire n'importe quoi ...
> > l'equivalent du casting entre type enumere.
>
> Là, je ne suis pas d'accord du tout. Tel que c'est fait, le développeur
> est obligé d'utiliser les instances fournies.
Je parlais de ma representation du type enumere (si on peut appeler ca
un type enumere !) par rapport a la classe qui en a besoin.
Et dans cette representation, comme j'utilise des entiers, l'utilisateur
peut les manipuler a son entendendement. De plus, quand je parlais du
casting entre type enumere, je me refere au type enumere du C (Jerome
demandais l'equivalent des types enumeres du C)
Je me suis peut etre mal exprimer la, ou tu as lu un peu trop vite. Ou
les deux :)
> Je veux bien un contre-exemple mais pas une affirmation telle quelle.
> (Au passage, on ne parle pas de C++ mais de Java !)
Pour le casting entre type enumere, je parlais du C. Donc je peux te
donner sans pb un contre-exemple :)
De plus, je ne pouvais pas parler de Java car les types enumeres n'y
existent pas. Et les types enumeres, tel qu'ils sont definis, n'ont rien
a faire en objet parce que ca ne veut pas dire grand chose.
>
>
> Peut-être douteuse mais il est impossible de type-cast ce genre
> d'objet
> et la vérification à la compilation simplifie plus l'écriture
> du code (par l'absence de check) et améliore son efficacité.
Penser objet d'abord, penser technique apres. Ca evite de faire de la
cuisine comme j'en rencontre trop souvent.
> Dans ce cas précis, on consomme plus de mémoire (les instances du type
> énuméré - qui sont de taille très raisonnables) mais on gagne en cycles
> CPU par l'absence de check à chaque appel des méthodes concernées.
Non, c'est pas tout fait exacte. La creation d'objet en Java est non seulement
couteux en memoire, mais en cycles CPU.
Quant au check il est non seulement leger mais il est aussi utilise que
lorsqu'il est necessaire.
>
> Oui c'est une réussite mais combien de fois le développeur peste sur
> une erreur de runtime que le compilateur aurait pu trouvé.
>
Va sur comp.object, dis leur ca et tu vas connaitre ta douleur. J'ai eu
le malheur de participer a une discussion sur typage static et
typage dynamique, et j'ai eu tres mal (je defendais le typage static).
Faut dire aussi qu'a leur
gouverne, lorsque je faisais du SmallTalk, je n'avais pas tant d'erreur
que ca par rapport a ce l'on dit sur les langages objets
a typage dynamique. Il faut juste programmer correctement ... peut etre
plus que d'habitude.
> Le typage fort et une expression du contrat des méthodes ont toujours
> abouti à des langages 'lourds'. Je pense à Ada en particulier.
> Mais le résultat est là:
> - on passe beaucoup de temps à écrire le source mais 99 % des erreurs
> possibles est rejeté à la compilation
> - en définitive, il devient "presque" inutile de faire des
> tonnes de tests pour assurer la converture du code,
> ce qui reste conseillé malgré tout ;) !
Tu parles a un convaincu. Mais la ou je ne suis pas d'accord, c'est sur
le fait qu'un typage fort donne un langage lourd. Le typage fort
concerne avant tout le compilateur.
De plus, je ne crois pas que l'on passe tant de temps que ca a ecrire du
code source (je pense a Eiffel par exemple.) Par contre, c'est bcp moins
souple que les langages a typage dynamique, ca oui.
> Mais alors montrez-moi le développeur qui fournit des tests unitaires
> automatiques (pour la non-régression) avec son code et vous dit:
> j'ai essayé de couvrir tous les cas.
>
Tu peux me tutoyer :)
Connais pas de tels developpeurs et c'est inutile en pratique.
> C'est pour cela que je préfère faire confiance au compilateur:
> - on perd du temps à écrire le source pour qu'il passe la compilation
> - on gagne beaucoup de temps sur la phase de tests
> (car rares sont les tests qui échoue ensuite)
Non, tu passes peut etre moins de temps en tests (ca reste encore a
prouver), mais pas tant que ca. Je me base sur mon experience et sur
celles de personnes que je ou j'ai cotoye. Ce qui ne veut pas dire que
dans certaines situations, le temps passe en tests avec un langage a
typage fort n'est pas largement inferieur a celui passe en tests avec un
langage a typage dynamique.
--
Miguel Moquillon <miguel.moquillon@???>
http://miguel.moquillon.free.fr
