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 !!!