En Eiffel, le concept objet est poussé a l'extrème. On le voit par exemple dans la proposition pour faire du parallélisme SCOOP (toujours aucune implémentation...).
En Sather, les concepteurs ont essayé d'orthogonaliser au maximun les concepts afin de les rendre le plus possible indépendant (concept d'orthogonalisation, si tu déplaces sur un axe, tu restes immobile sur un autre).
Donc, le concept d'héritage est divisé en deux : héritage d'interface et héritage de code. L'héritage d'interface suis le principe classique de la programmation objet lorsqu'une classe hérite d'une autre. Cependant, en Sather, elle n'hérite d'aucun code ! Il faut écrire explicitement l'héritage de code via le mot clef "include". Du coup, cela résoud très proprement les problèmes d'héritage multiple (au niveau des appels de méthodes, notament de même nom), a vrai dire, cela parait tellement simple qu'il n'y a plus de problèmes.
L'arbre des classe est très simple et permet le "supertyping". On peux créer une classe et dire que des classes déjà implémenté hérite de celle-ci !! C'est absolument génial pour étendre une librairie toute faite ou en corrigé des manques (inévitables).
Au niveau du parallélisme, les concepts en jeu sont a 100 lieu de SCOOP mais ca marche (enfin, ca marchait) et c'est clair à comprendre et a utiliser. Il y a même une extension "cluster" ou tu peux rajouter à toute instruction la chaine '@numerodunoeud" ou tu impose le noeud du cluster. Ca marche même sur les structures de donnée comme un tableau dont les éléments seraient physiquement imposés par le programmeur sur les différents noeuds du cluster.
Pour faire des boucles "loop do done", il y a un concept d'iterateur basé sur la notion de coroutine. Grace a ce concept, on évite l'usine a gas de la double structure de classe pour les conteneurs de données. L'arbre des classes n'en ai que plus simple. Grace a ce concept d'itérateur indépendant de le notion de classe et d'objet mais de même niveau que la notion de méthode, on divise par deux le nombre de classe (j'exagère) et on simplifie énormément les implémentations, laissant le compilateur optimisé le code ;-)
Bref, le langage a quelques defauts mais comme l'équipe qui l'avait développé faisait du calcul parrallèle, ils ont privilégié la simplicité et l'efficacité. Au final, on a un langage efficasse qui est un cousin d'Eiffel mais particulièrement attachant.
[^] # Re: J'espère....
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
En Eiffel, le concept objet est poussé a l'extrème. On le voit par exemple dans la proposition pour faire du parallélisme SCOOP (toujours aucune implémentation...).
En Sather, les concepteurs ont essayé d'orthogonaliser au maximun les concepts afin de les rendre le plus possible indépendant (concept d'orthogonalisation, si tu déplaces sur un axe, tu restes immobile sur un autre).
Donc, le concept d'héritage est divisé en deux : héritage d'interface et héritage de code. L'héritage d'interface suis le principe classique de la programmation objet lorsqu'une classe hérite d'une autre. Cependant, en Sather, elle n'hérite d'aucun code ! Il faut écrire explicitement l'héritage de code via le mot clef "include". Du coup, cela résoud très proprement les problèmes d'héritage multiple (au niveau des appels de méthodes, notament de même nom), a vrai dire, cela parait tellement simple qu'il n'y a plus de problèmes.
L'arbre des classe est très simple et permet le "supertyping". On peux créer une classe et dire que des classes déjà implémenté hérite de celle-ci !! C'est absolument génial pour étendre une librairie toute faite ou en corrigé des manques (inévitables).
Au niveau du parallélisme, les concepts en jeu sont a 100 lieu de SCOOP mais ca marche (enfin, ca marchait) et c'est clair à comprendre et a utiliser. Il y a même une extension "cluster" ou tu peux rajouter à toute instruction la chaine '@numerodunoeud" ou tu impose le noeud du cluster. Ca marche même sur les structures de donnée comme un tableau dont les éléments seraient physiquement imposés par le programmeur sur les différents noeuds du cluster.
Pour faire des boucles "loop do done", il y a un concept d'iterateur basé sur la notion de coroutine. Grace a ce concept, on évite l'usine a gas de la double structure de classe pour les conteneurs de données. L'arbre des classes n'en ai que plus simple. Grace a ce concept d'itérateur indépendant de le notion de classe et d'objet mais de même niveau que la notion de méthode, on divise par deux le nombre de classe (j'exagère) et on simplifie énormément les implémentations, laissant le compilateur optimisé le code ;-)
Bref, le langage a quelques defauts mais comme l'équipe qui l'avait développé faisait du calcul parrallèle, ils ont privilégié la simplicité et l'efficacité. Au final, on a un langage efficasse qui est un cousin d'Eiffel mais particulièrement attachant.