2 Sep
2004
2 Sep
'04
5:44 p.m.
Thierry GERAUD wrote:
Jerome Darbon wrote:
désolé de l'avoir oublié ; tu étais ma seule interface
de ce binôme
Il n'y a pas a etre desole
en fait non (mais je reconnais n'avoir pas été très clair) ; ce
bla-bla suit le paragraphe :
"Si vous trouver un langage ou un outil qui nous permette
d'être aussi générique et rapide qu'olena, très bien. Mais
faites de vrais tests, des tests pertinents. Ca nous sera
utile et votre travail sera béni."
je fais donc allusion à la catégorie "pour d'autres langages
que le C et C++"
ok.
ok pour ne pas *revendiquer* une comparaison mais cependant
il faut être à même de comparer pour, ne serait-ce que, situer
son travail.
cf. la reponse suivante.
pour résumer, l'approche "building
blocks" (et "composing") est
beaucoup moins monolitique que celle d'olena et elle est /a priori/
bcp plus prometteuse. la précaution prise par le "a priori" vient
du fait que c'est encore de la recherche : à quel point peut-on
composer facilement et sans problème ? comment faire pour appliquer
ces techniques pour un domaine d'application (quelles sont les
briques logicielles) ?
Je pense qu'il ne faut pas confondre type de donees et ecriture
d'algorithmes. L'embryon de bibliotheque avec proprietes a
la vocation (j'entends que je lui prete cette vocation) : montrer
qu'a partir du moment ou on a ces proprietes on peut ecrire les
algorithmes "a la" maniere presente dans ecoop-phd. Mon but n'est pas,
et n'a jamais ete, d'ecrire un "core" Olena. J'exhibe les
caracteristiques *necessaires* (pour la condition de suffisance, je
ne m'y attaquerai pas) que doit posseder ces types pour utiliser
la solution proposee dans eccop-phd.
Le point le plus difficile etait deja de pouvoir declarer
des varianbles !!!