L'année a été riche en nouveautés. Beaucoup de progrès ont été fait côté compilateur, mais aussi côté bibliothèques et confort des utilisateurs. Certains projets externes ont vu le jour (Eiffel Wrapper Libraries Collection - EWLC, Entreprise SmartEiffel - ESE, Useful SmartEiffel - USE) dont les acteurs ont fortement contribué aux améliorations de cette nouvelle fournée.
Cette bêta annonce la sortie prochaine (espérons-le) de la version stable 2.3, ce que certains développeurs de SmartEiffel attendent pour pouvoir intégrer leurs tous derniers changements ("bord coupant" :-) dans la future version 2.4. Au programme des nouveautés de cette bêta :
- Clarification des règles de conformité (lien insert/inherit) : détails sur la page Typing_policy du wiki ;
- Nouvel algorithme pour le chargement des classes. Cet algorithme tient compte de la "distance" entre les classes pour décider laquelle utiliser. Lorsqu'il existe deux classes avec le même nom, le compilateur parcourt l'arbre formé par les fichiers loadpath.se pour trouver la classe la plus "proche" (au sens "répertoire à parcourir"), d'abord en profondeur puis en arrière ;
- Installation améliorée : un effort a été consenti sur la fin pour permettre un meilleur packaging dans les distributions (certains ont peut-être remarqué la présence d'un paquet 2.2.99 dans Debian unstable) ;
- Configuration améliorée : l'ancien fichier ~/.serc (ou /etc/serc) a été remplacé par un répertoire du même nom. A l'intérieur de celui-ci peuvent maintenant se trouver plusieurs fichiers de configuration (leurs noms importent peu). Ceci permet une meilleure intégration de paquets externes nécessitant des fichiers de configuration (EWLC/USE/ESE ?) ;
- Le paramètre -debug_check est périmé. Un nouveau paramètre -debug permet d'activer les blocs debug ;
- L'ancienne classe READY_DESCRIPTION du séquenceur a été remplacée par la classe EVENTS_SET pour unifier tout type d'évènements ;
- La bibliothèque a été un peu améliorée, notamment avec RECYCLING_POOL pour permettre la réutilisation d'objets ;
- Les clusters net, exec et xml ont été améliorés, avec notamment une validation par DTD automatique et un parseur "namespace-aware" ;
- Un nouveau cluster "language" est apparu. Son but est d'héberger des interfaces vers d'autres langages, notamment les langages de script. Pour le moment, seul Perl est représenté ;
- Le fameux bug des inspects sur STRING a été éradiqué, ainsi que de nombreux autres bugs un peu partout.
Aller plus loin
- SmartEiffel (1 clic)
- SE sur Gforge (1 clic)
# Eiffel, trop tard ...
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Maintenant, il aura d'autant plus de mal avec d'une part le Eiffel de NICE et le Eiffel de l'ECMA. Sur lequel pouvons nous vraiment miser ? Décidément, Meyer n'a jamais su vraiment profiter ou créer les opportunités qu'il fallait.
A côté de ceci, il y a l'arrivée de nouveaux langages objets comme par exemple Lisaac ou Io, et ceci sans parler du renouveau de Smalltalk, toutjours imité, mais jamais vraiment égalé (si ce n'est peut-être par Self), avec par exemple Squeak, seaside, ... et probablement dans un future plus ou moins proche, StrongTalk.
De plus actuellement, l'environnement des langages objets utilisés dans l'industrie s'est grosso-modo bipolarisé avec d'un côté la plateforme Java et de l'autre C# et sa plateforme .NET.
[^] # Re: Eiffel, trop tard ...
Posté par pini . Évalué à 3.
A noter à propos de lisaac, un rapprochement est en cours entre l'équipe de SmartEiffel et celle de Benoit Sonntag, qui donnera sans doute naissance à un outil eiffel_to_lisaac.
[^] # Re: Eiffel, trop tard ...
Posté par Ontologia (site web personnel) . Évalué à 2.
Connaissant la rigueur extrême, voire la maniaquerie des deux protagonistes, ça devrait prendre quelques temps, mais le plus gros est fait.
Il y a eu beaucoup d'échanges d'idées et Eiffel devrait s'inspirer de certains de Lisaac(le futur modèle de concurence COP par exemple).
D. Colnet et B. Sonntag se sont aussi bien vite rendu compte que'un traducteur Lisaac_to_eiffel était malheureusement impensable. Dommage, une passerelle entre les deux aurait été sympa...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Eiffel, trop tard ...
Posté par GTS . Évalué à 2.
Tous les concepts qui font recette en programmation orienté objet s'y retrouvent.
Cependant le programmeur-bidouilleur est souvent frustré car le manque de communauté en fait un langage très peu fourni en librairies "annexes".
La compilation SmartEiffel passe, de mémoire, par une "traduction" en C.
Et c'est là qu'on est le plus souvent frustré, puisque le C est bien plus complet que l'eiffel.
On ne va pas par exemple re-coder l'OpenGL pour pouvoir l'utiliser en Eiffel !
Je n'ai hélas pas eu le courage de pousser plus loin mon expérimentation d'Eiffel à cause de ces "défauts".
C'est dommage car j'avais bien accroché aux concepts du langage.
[^] # Re: Eiffel, trop tard ...
Posté par viridis (site web personnel) . Évalué à 2.
La facilité d'interfacer du C avec SmartEiffel permet d'avoir facilement et rapidement accès à toutes les bibliothèques C...et ce, spécialement pour les "bidouilleurs"..
De plus, un vrai "bidouilleur" n'est jamais avare en écriture de wrapper ou autres :)
Un widget vision (le système de GUI de SmartEiffel) est dispo depuis longtemps...
Ceci dit, je comprend les arguments, mais comme le dit pini, c'est un cercle vicieux à transformer en cercle vertueux !
[^] # Re: Eiffel, trop tard ...
Posté par Rémi Pannequin . Évalué à 3.
C'est aussi mon cas, mais il était maître de conf dans mon école d'ing. (Je pense qu'on parle de la même personne...) :-)
Eiffel est vraiment un langage agréable, car il permet d'utiliser très simplement toutes les fonctionnalités des langages à objets. Le langage mets en oeuvre en plus le paradigme de programmation par contrat, qui constitue une alternative très intéressante aux outils de tests unitaires (a la JUnit).
Ha nostalgie ! Quand je pense que je n'écris plus qu'en java (et en VB /o\ )...
# GOBO : une autre alternative
Posté par olympien . Évalué à 5.
Pour développer en Eiffel, je conseille vivement EiffelStudio, un excellent IDE.
J'ai travaillé sur une extension d'Eiffel (implémentation de l'héritage inverse) et j'ai trouvé le langage trés intéressant.
Ces nombreux mécanismes exploitent plein de bonnes idées qu'on peut trouver dans le paradigme objet.
[^] # Re: GOBO : une autre alternative
Posté par Jazz . Évalué à 4.
http://eiffelsoftware.origo.ethz.ch/
# Eiffeldoc et ravalement de façade...
Posté par viridis (site web personnel) . Évalué à 2.
Le plus simple c'est d'aller voir ce que ça donne par ici :
http://smarteiffel.loria.fr/libraries/index.html
Nouveau style donc, mais aussi nouvelles fonctionnalités avec entre autre une navigation plus facile (présence de "blocs dépliables" et plus de lien dans l'API) et davantage d'informations affichées.
On notera que le site du projet a fait peau neuve également bien qu'il reste certaines vieilles pages :
http://smarteiffel.loria.fr/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.