![[Visitors]](http://www.eiffelsolution.com//LogMeThis/visitors.png.php?app=GFUE&hide=1)
EIFFEL: Foire aux questions
Cette foire aux questions est une adaptation de sa sœur anglaise du groupe comp.lang.eiffel. (http://www.faqs.org/faqs/eiffel-faq/)Veuillez envoyer corrections et commentaires à Emmanuel_Bouyer@tiscali.co.uk
Aucune garantie n'est faite concernant l'exactitude de toutes les informations de cette faq.
Cette traduction a été initialement faite par Franck Arnaud et Emmanuel Bouyer.
Vous avez le droit de distribuer tout ou parties de ce document sans aucune restriction.
Vous pouvez obtenir la dernière mise à jour sur Internet à l'adresse suivante: http://www.eiffelsolution.com/hosting/gfue/faq.php
Quoi de neuf ?
Changements depuis la dernière version (20 février 2004)- Quelques typo ont été corrigées.
- La page a été aérée.
Index:
Questions les plus fréquentes :QEIF: Qu'est-ce Eiffel ?
QORI: D'où vient Eiffel ?
QCOM: Quels sont compilateurs d'Eiffel ?
QLIB: Quelles sont les bibliothèques disponibles en Eiffel ?
QFRE: Eiffel est-il disponible en tant que logiciel libre ?
QARC: Y a-t-il des archives du newsgroup de comp.lang.eiffel ?
QBOK: Quels livres puis-je lire pour apprendre Eiffel ?
QWEB: Où puis-je trouver Eiffel sur internet ?
QEDI: Où puis trouver un éditeur ou un mode Emacs pour Eiffel ?
QBON: Qu'est-ce que BON ?
QSTD: Y a-t-il des normes pour le langage Eiffel ?
QPOR: Comment puis-je écrire des applications portables ?
QTGV: Quelle est la vitesse d'exécution des applications Eiffel ?
QGRP: Y a-t-il des groupes d'utilisateurs d'Eiffel ?
QADR: Où puis-je trouver des produits et des services Eiffel ?
QCNF: Y a-t-il des conférences pour des utilisateurs d'Eiffel ?
QECC: Pourquoi la plupart des implémentation d'Eiffel génèrent du C ?
QJVM: Où puis-je trouver un compilateur Eiffel vers Java ?
QNET: Où puis-je trouver un compilateur Eiffel vers .NET ?
Problèmes liés au langage :
LFEA: Quelles sont les fonctionnalités d'Eiffel
?
LCHN: Quels changements ont été faits
à la définition du langage Eiffel ?
LLIB: Quelles bibliothèques sont livrées
avec Eiffel ?
LDBC: Pourquoi tant de remous à propos des preconditions
et des postconditions ?
LCQS: Pourquoi séparer les requêtes des
commandes ?
LCON: Qu'elle est la différence entre la covariance
et la contravariance ?
LCAT: Il y a t-il vraiment des trous dans le système
de type?
LTSK: Eiffel permet-il d'écrire des applications
parallèles?
LOVL: Pourquoi Eiffel ne permet-il pas de surcharger
les fonctions?
LINC: Pourquoi n'y a t il pas d'opérateur d'incrémentation?
LAGE: Que sont les 'agents' Eiffel?
LATR: Pourquoi n'y a t-il pas d'attributs de classe
en Eiffel?
LPAR: Comment appeler l'ancêtre d'une routine
redéfinie?
LEVC: Où trouve t-on une comparaison entre Eiffel
et d'autres langages?
LDES: Il y a t-il des destructeurs en Eiffel?
LDIS: Comment implémenter au mieux l'héritage
multiple?
LISA: Comment fonctionne l'exemple d'itération
multiple d'ETL?
LORB: Est-ce que COM/CORBA est supporté?
Questions les plus fréquentes
QEIF: Qu'est-ce Eiffel ?
Eiffel est un langage et une méthode de programmation orientés objets qui souligne la conception et la construction du logiciel de grande qualité et réutilisableEiffel n'est pas un l'extension ni le dérivé d'aucun autre langage. Eiffel encourage fortement la programmation objet. Il ne permet pas des pratiques dangereuses des langages de générations précédentes bien qu'il connecte à d'autres langages tels que C et C++. Eiffel soutient le concept de la conception par contrat (Design by Contract) pour améliorer la qualité des logiciels.
Au delà de l'aspect langage informatique, Eiffel est une méthode de construction de logiciel. Eiffel est un excellent outil pour apprendre à concevoir des logiciels. C'est aussi un très bon support pédagogique pour un cours d'initiation à la programmation.
QORI: D'où vient Eiffel ?
Eiffel a été créé par Bertrand Meyer et développé par son entreprise, Eiffel Software Incorporated située à Goleta en Californie.Docteur Meyer s'est servi de sa large expérience de l'approche objet, en particulier avec Simula. Son travail universitaire sur la vérification de logiciel et la définition de langage de programmation lui a également inspiré quelques concepts fondamentaux d'Eiffel.
La conception de logiciels en Eiffel adresse beaucoup de problèmes pratiques auxquels les développeurs de logiciels complexes sont confrontés. Eiffel a évolué sans cesse depuis sa conception le 14 septembre 1985 et depuis sa première introduction en 1986.
Eiffel tient son nom de Gustave Eiffel, l'ingénieur qui a conçu la tour Eiffel.
QCOM: Quels sont compilateurs d'Eiffel ?
Les compilateurs suivants sont actuellement disponibles et supportés par leurs fournisseurs ou auteurs. Les compilateurs sont listés en ordre chronologique de première publication.Pour les produits commerciaux, le prix n'est pas mentionné parce qu'il peut changer en fonction des plateformes, du mode d'utilisation (personnelle, universitaire, professionnelle), ou d'autres paramètres. Veuillez vérifiez les prix en suivant les liens des fournisseurs.
Dans la liste ci-dessous, la 'cible' est le code produit par le compilateur. La plupart des compilateurs produisent du code C. Il peut être nécessaire d'avoir un compilateur C. Quelques compilateurs ou distributions sont livrés avec un compilateur C gratuit.
plateformes indique la ou les plateformes supportées. Win32 signifie la version de 32 bits de Windows sur Intel x86. Unix signifie divers Unices. Veuillez vérifier avec le fournisseur pour une liste précise des plateformes supportées. Tous les compilateurs fonctionnant sous Unix fonctionnent sous Linux sur Intel x86.
Fournisseur : Eiffel Software, Inc., États-unis
Produit : EiffelStudio/Eiffel ENViSioN
Licence : Commerciale ; gratuit pour tout usage non commercial
Cible : C/.Net
Plateformes : Win32, Unix, .NET, VMS
Web : http://www.eiffel.com/
Description : Ce produit, auparavant connu sous le nom d'Ise Eiffel,
est disponible comme environnement de développement complet (EiffelStudio)
ou intégré dans Visual Studio pour .NET (Eiffel ENVisioN).
Il inclut:
- un environnement de développement graphique complet avec les fonctionnalités uniques et puissantes pour parcourir le code, documenter, repérer et corriger les erreurs symboliques, compiler rapidement. Il contient également un outil de diagramme basé sur la méthode BON.
- EiffelBase, également disponible sous licence open source , est une librairie complète et professionnelle de classes recouvrant les containeurs, collections, entrées/sorties, itérateurs, persistance d'objet, recherche, etc.
- EiffelVision2, une puissante bibliothèque graphique multi plateforme.
- sous Windows, la bibliothèque de Windows Eiffel (WEL) combine la puissance d'Eiffel avec l'interface Windows et la bibliothèque d'EiffelCOM pour créer et réutiliser des composants COM.
- beaucoup d'autres bibliothèques: EiffelNet, EiffelLex, EiffelParse, EiffelWeb, EiffelStore, Eiffel2Java, EiffelThread, EiffelTime
Fournisseur : Dominique Colnet et autres
Produit: SmartEiffel, le compilateur Eiffel GNU
Licence : gratuit (GPL)
Cible : ANSI C / Machine virtuelle Java
Plateformes : Toute machine supportant ANSI C
Web: http://smarteiffel.loria.fr/
Description : SmartEiffel a l'intention d'être un compilateur
Eiffel complet et gratuit, disponible pour un éventail de plateformes,
tout en restant petit et très rapide. Il inclut un compilateur générant
du C, un autre générant du code assembleur Java, un outil
de documentation, un formateur de code source, etc. Le compilateur emploie
une stratégie innovatrice impliquant l'analyse entière du système
qui permet à la compilation d'être souvent plus rapide que
la compilation incrémentale des compilateurs traditionnels. Il a
été conçu (sous le nom de SmallEiffel) au laboratoire
de LORIA, Nancy, France, en 1994-95, et depuis a été employé
dans le monde entier par beaucoup d'individus et universités.
Fournisseur: Object Tools GmbH, Allemagne
Produit: Visual Eiffel
Licence: Commercial sous Win32 (évaluation libre); gratuit sous
Linux
Cible : Intel x86
Plateformes : Win32, Linux (outils de ligne de commande)
Web: http://www.object-tools.com/
ou http://www.eiffel.de/
Description : Visual Eiffel et DM (Display Machine) vous aideront à
développer des applications complexes sous Windows en un temps réduit.
Visual Eiffel vous donne :
- un environnement de développement intégré sous Windows
- un compilateur professionnel produisant du code natif, qui est très rapide pour les processeurs d'Intel
- DM : l'outil d'aide au développement plus rapide que vous n'ayez jamais vu vous donne tous les atouts pour rapidement développer des applications sous Windows.
- beaucoup de bibliothèques très utiles pour produire des applications commerciales sous Windows, pour intégrer des composants ActiveX, pour gérer les accès ODBC, pour créer de applications graphiques professionnelles et bien plus encore.
Produit: Eiffel pour OS X
Licence: Commerciale (évaluation libre)
Cible : C ANSI
Plateformes : Mac OS (Power PC)
Web: http://www.maceiffel.com/
Description: Basé sur le compilateur original de l'Eiffel/S d'Object Tools, Eiffel pour OS X tourne … sous OS X. Le compilateur est disponible en tant qu'extension d'Apple ProjectBuilder et/ou de MetrowWerks CodeWarrior. Il inclut les bibliothèques habituelles du noyau et également des bibliothèques standard d'Eiffel développées sur les interfaces Macintosh (Cocoa et Carbon). Une version antérieure, pour MacOS 8 et 9, est disponible à http://www.object-tools.com/products/eiffel-s/
D'autres compilateurs d'Eiffel valent la peine d'être mentionnés ici, bien qu'ils puissent ne plus avoir de support, ou n'être qu'une vieille version, ou n'être qu'en début de développement (et donc ne pas implémenter la totalité du langage).
- SIG Eiffel/S, version 1.3 : c'était le premier compilateur d'Eiffel 3, et le premier compilateur disponible sur PC. La version 1.3, sortie il y a quelques années, est encore disponible en shareware chez Object Tools (autrefois SIG) à http://www.object-tools.com/. C'est un compilateur en ligne de commande produisant du code de C. Il est disponible sous DOS32, Windows 95 et NT et beaucoup de plateformes d'Unix.
- TowerEiffel était un compilateur commercial avec une emphase sur la rapidité d'exécution du code généré. Il a cessé d'être activement soutenu et vendu après que Tower Technology ait décidé d'écrire un compilateur Java statique en utilisant des optimisations globales semblables à celles de la plupart des compilateurs d'Eiffel.
- iss-base était un compilateur et un environnement de Halstenbach ACT Gmbh. C'était tout d'abord un dérivé commercial d'Ise Eiffel. Mais le développement a bifurqué après et le cœur du compilateur a été développé indépendamment de celui d'ISE. Pendant un moment c'était l'un des compilateurs d'Eiffel les plus rapides. L'environnement de développement est demeuré presque inchangé. Des bibliothèques, développées indépendamment de tout autre fournisseur, et un générateur d'interface utilisateur ont été ajoutés. Le produit n'existe plus (officiellement).
- il y a eu de divers autres projets de compilateurs qui ne sont pas largement répandus: EON Eiffel, un compilateur d'Eiffel écrit en C++ et qui génère du C++, il n'est pas activement maintenu; J-Eiffel, un compilateur produisant du bytecode JVM, écrit par Pirmin Kalberer; et FEC de Fridtjof Siebert, un compilateur de code natif pour les Sun SPARC.
QLIB: Quelles sont les bibliothèques disponibles en Eiffel ?
Les vendeurs de compilateurs Eiffel fournissent habituellement un large ensemble de bibliothèques avec leurs compilateurs, et en proposent d'autres à coté.Beaucoup de bibliothèques, habituellement livrées en Open Source, sont fournies par des développeurs indépendants. Elles sont beaucoup trop nombreuses pour être énumérées ici. Allez à QWEB pour les sites de référence, qui contiennent des listes des bibliothèques disponibles.
Vous pouvez commencer par : http://www.cetus-links.org/oo_eiffel_libraries.html
QFRE: Eiffel est-il disponible en tant que logiciel libre ?
SmartEiffel est un compilateur Open Source, fourni comme un module C très portable. Il tourne sur la plupart des plateformes supportant ANSI C. Il inclut le code source complet du compilateur, lui-même écrit en Eiffel. Voir QCOM.Pour télécharger un module prêt à tourner pour Windows, y compris un compilateur C gratuit, allez voir à http://elj.sourceforge.net/
Beaucoup de versions commerciales offrent aussi une évaluation gratuite, la plupart du temps limitée. Les fournisseurs commerciaux offrent souvent des versions de base bon marché pour les plateformes populaires comme Win32 et Linux sur les PCs x86.
QARC: Y a-t-il des archives du newsgroup de comp.lang.eiffel ?
Oui, sur les newsgroups de Google: http://groups.google.com/groups?group=comp.lang.eiffelQBOK quels livres puis-je lire pour apprendre Eiffel ?
Les principaux éditeurs sont Addison Wesley (AW) et Prentice Hall (PH).Lecture de base
Titre : Conception et programmation orientées objet
Auteur : Bertrand Meyer
ISBN : 2-212-09111-7 ; Eyrolles 2000
Résumé: Ce livre est la référence complète sur tous les aspects de technologie objet, des principes de conception aux techniques objet, à la conception par contrat, à l'analyse objet, à la simultanéité, à la persistance, aux types de données abstraits... Tandis qu'Eiffel est seulement présenté comme notation employée pour illustrer le concept, ce livre est une lecture essentielle pour n'importe quel utilisateur d'Eiffel. Il inclut une description très complète de la notation. Il est livré avec un Cd-rom contenant le texte complet (en HTML), du matériel supplémentaire, et une version d'Ise Eiffel. Ce livre est la traduction française de la deuxième édition de Object Oriented Software Construction (ISBN : 0-13-629155-4 - Prentice Hall 1997)
Titre : Eiffel, the language
Auteur : Bertrand Meyer
ISBN : 0-13-247925-7 ; PH 1992
Résumé : Ce livre de 600 pages combine une introduction
à Eiffel avec une bonne part de réflexions sur le langage.
C'est un livre rigoureux et complet que quelques lecteurs peuvent trouver
assez lourd à lire en dépit de la clarté d'expression
de Dr. Meyer. C'est la référence absolue d'Eiffel, et une lecture
essentielle pour tous les utilisateurs sérieux d'Eiffel. La seconde
impression (sous le même ISBN) inclut beaucoup de corrections et changements
(il n'y a pas une deuxième édition, et aucune n'est actuellement
en cours). Ce livre est également disponible en français
(ISBN 2-7296-0525-8).
Autres livres
Titre : Design by Contract, by Example
Auteur : Richard Mitchell, James McKim
ISBN : 0-20-163460-0 ; AW 2001
Résumé : Un guide par l'exemple basé sur la conception
par contrat.
Titre : Design Patterns and Contracts
Auteur : Jean-Marc Jezequel, Michel Train, Christine Mingins
ISBN : 0-20-130959-9 ; AW 1999
Résumé : Ce livre est tiré des travaux sur la
conception logicielle décrits dans le livre du fameux groupe des
quatre par Gamma et Cie. La conception par contrat est appliquée
aux modèles de conception.
Titre : Objets Unencapsulated: Java, Eiffel, et C++?
Auteur : Ian Joyner
ISBN : 0-13-014269-7 ; PH 1999
Résumé : Un examen du noyau de la technologie orientée
objet qui passe par une comparaison entre Java, Eiffel et C++.
Titre: Object Oriented Programming in Eiffel, 2ème édition
Auteur : Peter Thomas et Ray Weedon
ISBN : 0-201-33131-4 ; AW 1997
Résumé : Ce livre est un cours pédagogique et
un manuel très complet d'Eiffel, avec une bonne approche des types
abstraits de données.
Titre : Algorithms and Data Structures
Auteur: Jeffrey Kingston
ISBN: 0-201-40374-9 ; AW 1997
Résumé : Un traitement des structures centrales d'algorithmes
et de données en informatique. Ce livre inclue des implémentations
complètes en Eiffel.
Titre : An Object-Oriented Introduction to Computer Science
Auteur : Richard Wiener
ISBN : 0-13-838725 ; PH 1997
Résumé : Aucun
Titre : Object Technology for Scientific Computing Object-Oriented
Auteur : Paul Dubois
ISBN : 0-13-267808-X ; PH 1996
Résumé : CD livré avec Free Eiffel pour Unix et
Linux.
Titre : Object-Oriented Software Engineering with Eiffel
Auteur : Jean-Marc Jezequel
ISBN : 0-201-63381-7 ; AW 1996
Résumé : Un guide complet d'Eiffel. En plus de décrire
Eiffel, ce livre décrit et compare les différents compilateurs
et bibliothèques disponibles sur le marché.
Titre : Object Structures: Building OO Software Components with Eiffel
Auteur : Jacob Gore
ISBN : 0-201-63480-5 ; AW 1996
Résumé : C'est le premier livre de structures de données
pour Eiffel. Il est le premier à étudier d'une manière
systématique cet aspect essentiel de n'importe quel langage de programmation.
Titre: Eiffel Object-Oriented Programming
Auteur: John Tyrrell
ISBN : 0-333-64554-5; ?? 1995
Résumé : C'est un livre bon marché et très
accessible.
Titre: Software Development Using Eiffel: There can be life other than
C++
Auteur: Richard Wiener
ISBN: 0-13-100686-X ; PH 1995
Résumé: C'est un livre utile avec beaucoup d'exemples
de code pour les lecteurs qui connaissent déjà un autre langage
objet.
Titre: Object Success
Auteur: Bertrand Meyer
ISBN: 0-13-192833-3 ; PH 1995
Résumé: C'est un guide pour les chefs de projets. Il
étudie la programmation objet, son impact sur l'entreprise et son
utilisation pour améliorer le développement de logiciels.
Titre: Object Oriented Programming in Eiffel
Auteur: R. Rist et R. Terwilliger
ISBN: 0-13-205931-2 ; PH 1995
Résumé: C'est un manuel qui traite principalement de
la conception en Eiffel.
Titre: Seamless Object-Oriented Software Architecture: Analysis and
Design of Reliable Systems
Auteur: Kim Walden et Jean-Marc Nerson
ISBN: 0-13-031303-3 ; PH 1994
Résumé: Ce livre décrit en détails la méthode
BON.
Titre: Reusable Software: The Base Object-Oriented Component Libraries
Auteur: Bertrand Meyer
ISBN: 0-13-245499-8 ; PH 1994
Résumé: Ce livre décrit des principes de conception
de bibliothèques et de la taxonomie des structures informatiques
de base. C'est aussi un manuel d'utilisation des bibliothèques EiffelBase.
Titre: An Object-Oriented Environment: Principles and Application
Auteur: Bertrand Meyer
ISBN: 0-13-245507-2 ; de PH 1994
Résumé: Ce livre décrit l'environnement d'Ise
EiffelBench ainsi que la technologie de compilation Melting Ice
et le générateur d'interface graphique EiffelBuild.
Titre: Object-Oriented Applications
Auteur: Meyer et de Nerson (rédacteurs)
ISBN: 0-13-013798-7 ; PH 1993
Résumé: Ce livre inclut une introduction à la
technologie Eiffel suivie de sept descriptions détaillées
de larges applications écrites en Eiffel.
Titre: Eiffel: An Introduction
Auteur: Robert Switzer
ISBN: 0-13-105909-2 ; PH 1993
Résumé: Ce livre est une introduction très claire
et concise d'Eiffel. Il contient avec beaucoup de fragments de code et
deux applications substantielles en Eiffel. Il est aussi disponible en français
(ISBN 2-225-84-656-1).
Titre: Object Oriented Software Construction, première édition
Auteur: Bertrand Meyer
ISBN: 0-13-629049-3 ; PH 1988
Résumé: Une édition précédente de
la deuxième édition mentionnée ci-dessus, basée
sur une version précédente du langage. Est aussi disponible
en français, allemand, italien, hollandais, etc...
QWEB: Où puis-je trouver Eiffel sur internet ?
http://www.cetus-links.org/oo_eiffel.htmlCetus est un annuaire des ressources sur la programmation orientée objet, il contient aussi des pages très utiles sur Eiffel.
http://www.eiffel-nice.org/
Page d'accueil de NICE, l'organisme chargé de la standardisation
d'Eiffel.
http://www.gobosoft.com/
Page d'accueil du projet Gobo Eiffel.
Les sites des principaux fournisseurs sont :
Eiffel Software http://www.eiffel.com/
Object Tools http://www.object-tools.com/
SmartEiffel http://smarteiffel.loria.fr/
QEDI où puis trouver un éditeur ou un mode Emacs pour Eiffel ?
- Tower Techology a développé un mode emacs pour Eiffel 3. Ce mode met en évidence la syntaxe, a une indentation automatique et est facilement modifiable pour s'adapter aux besoins spécifiques (changement de police, de couleur, d'indentation).
- WINEDIT dispose d'une mise en couleur de la syntaxe. Il fonctionne avec Eiffel/S sous MS-Windows, et est disponible toutes les archives de shareware sous Windows.
- PFE (Programmers File Editor) d'Alan Philips fonctionne également avec Eiffel/S sous MS-Windows. Il a des templates mais pas de mise en couleur de la syntaxe. Il est disponible à : http://www.lancs.ac.uk/people/cpaap/pfe/
- L'éditeur vim, une version étendue de vi d'Unix, inclut dans sa distribution standard un fichier de Reimer Behrend contenant la syntaxe d'Eiffel. Il est téléchargeable à http://www.vim.org/
- Une extension Eiffel de Codewright (éditeur de texte sous Windows développé par Premia) offre un chromacoding d'Eiffel, une indentation intelligente et de quelques templates ; voir à : http://www.nenie.org/eiffel/free/
- TextPad (http://www.textpad.com/ ) peut être étendu et comprendre alors un certain nombre de syntaxes d'Eiffel.
QBON qu'est-ce que BON ?
BON (Business Object Notation) est une méthode pour l'analyse et la conception à haut niveau. Cette méthode offre une transition réversible vers une implémentation en Eiffel. Elle souligne la conception par contrat (Design by Contract) et le développement systématique. Elle est décrite dans le livre 'Seamless Object-Oriented Software Architecture' (Walden et Nelson) qui est téléchargeable à http://www.bon-method.com/ avec d'autres ressources sur la méthode.EiffelStudio d’Eiffel Software supporte la méthode BON.
QSTD: Y a-t-il des normes pour le langage Eiffel ?
La définition du langage Eiffel est dans le domaine public. Cette définition été auparavant contrôlée par NICE (Non-profit International Consortium for Eiffel), un groupe de fournisseurs et d'utilisateurs d'Eiffel. Site: http://www.eiffel-nice.org/La définition du langage est donnée dans le livre de Bertrand Meyer, « Eiffel: The language » (2ème Impression). Ceci est modifié pour la bibliothèque du noyau (ELKS) par des documents de NICE: Elks-95 avec des mises à jour pour des classes spécifiques. La version originale et les mises à jour sont toutes disponibles sur le site de NICE.
Un comité d'Ecma a été maintenant mis en place pour obtenir plus rapidement une norme ISO. Le résultat de ce processus sera édité dans la troisième édition d' « Eiffel: The language », dont une ébauche est accessible sur la page de Bertrand Meyer: http://www.inf.ethz.ch/personal/meyer/
NICE se charge de la standardisation de la bibliothèque du noyau tandis que le comité d'Ecma se concentre sur le cœur du langage.
L'adhésion à NICE est actuellement libre. Les gens intéressés par la standardisation et la promotion d'Eiffel peuvent joindre NICE sur le site web. Des listes de diffusion sont disponibles pour discuter sur les sujets d'intérêt communs à la communauté Eiffel et à NICE.
Les membres du conseil de NICE pour 2003 sont Joseph Kiniry, Frieder Monninger, Berend de Boer et Franck Arnaud.
QPOR: Comment puis-je écrire des applications portables ?
Il est possible d’écrire des applications facilement portables d’un compilateur à un autre, pour peu que l’on évite d’utiliser des fonctions spécifiques à un compilateur ou des nouveaux mécanismes pas encore stabilisés ou d’obscures fonctions du langage dont les implémentations peuvent varier d’un compilateur à l’autre ou d’une version à l’autre.Il est généralement immédiat de porter une application d'un système d’exploitation à un autre pour autant que l'on garde le même compilateur Eiffel.
La situation est moins franche avec les bibliothèques. La seule norme officielle pour les bibliothèques est la norme du noyau Elks-2001. Les dispositifs et les classes de noyau sont portables d’un compilateur à un autre si aucun dispositif spécifique à un fournisseur n’est utilisé. Cela limite un tant soit peu les fonctionnalités utilisables.
Elks-2001 n'inclut pas de classes de conteneurs (sauf ARRAY). Eiffel Software fournit maintenant sa bibliothèque de structure de données, EiffelBase, gratuitement avec les sources (open source). Cette bibliothèque tourne avec certains autres compilateurs mais pas avec tous.
La bibliothèque Gobo d'Eric Bezault (http://www.gobosoft.com/) est probablement la bibliothèque alternative le plus largement répandue. Eric l’a rendue complètement portable pour tous les compilateurs courants. Elle inclut un cluster qui émule EiffelBase si bien que la plupart des applications développées en utilisant EiffelBase peuvent être facilement adaptées à n'importe quel compilateur en utilisant Gobo. En plus des structures de données, Gobo inclut des fonctionnalités essentielles non couvertes par Elks-95 ainsi que des abstractions de quelques différences entre les compilateurs Eiffel.
QTGV: Quelle est la vitesse d’exécution des applications Eiffel ?
Eiffel est un langage orienté objet statiquement typé qui utilise une gestion automatique de mémoire.Beaucoup de compilateurs Eiffel utilisent le typage statique ainsi que des optimisations globales pour générer des exécutables qui tournent aussi rapidement que s’ils avaient été développés sous un autre langage à type statique, tel C++.
Les assertions en Eiffel sont normalement activées pendant la phase de développement, et ralentissent inévitablement l'exécution. Les assertions ne sont généralement pas compilées dans la version finale de l’exécutable (en production). Elles n'ont donc aucun impact sur l'exécution du code optimisé.
Le coût gestionnaire de mémoire (Garbage Collector ou ramasse miette) est un autre point souvent discuté. Il est vrai que les grandes applications passent souvent plus de temps à gérer leur mémoire plutôt que d’effectuer d’autres opérations. En principe un modèle de programmation qui présume l’existence d’un gestionnaire de mémoire est plus efficace qu’une gestion manuelle typique de mémoire. De toute façon, il n'y a rien dans Eiffel rendant la gestion de mémoire moins efficace que dans n'importe quel autre langage où elle est employée.
QGRP: Y a-t-il des groupes d'utilisateurs d'Eiffel ?
Les fournisseurs de compilateur maintiennent habituellement des groupes d'utilisateurs pour leur base d'utilisateur, souvent sous forme de liste de diffusion ou de réunions pendant les conférences. Contactez les différents fournisseurs pour plus d'information.Il existe un certain nombre de groupes de discussion en ligne sur Eiffel à http://www.talkitover.com/ et sur les groupes de Yahoo (http://groups.yahoo.com/). Ces sites fournissent une interface mail et web.
Beaucoup de projets d'Eiffel sont sous Sourceforge, le site des sources gratuits (Open Source). http://www.sourceforge.net/
Les utilisateurs sud-américains d'Eiffel peuvent regarder la page
d’accueil de RIPLEG (Rio de la Plata Eiffel Group). http://www.ripleg.com.ar/
Le groupe d'utilisateurs d’Eiffel du Colorado se réunit à Denver et a une liste de diffusion à http://groups.yahoo.com/group/colorado_eiffel_users/
QADR: Où puis-je trouver des produits et des services Eiffel ?
Ces fournisseurs, revendeurs, enseignants et consultants Eiffel sont énumérés par ordre alphabétique:- Advanced Media Technology Ltd, http://www.eiffel.fi (Jukka Haukijarvi, jukka.haukijarvi@eiffel.fi)
- Cap Gemini France, Division ITMI, http://www.capgemini.fr/ (Jean Marc Nerson, jnerson@capgemini.fr)
- Class Technology Pty. Ltd, http://www.class.com.au/ (bureau Eiffel, eiffel@class.com.au)
- Eiffel Ireland, http://www.eiffel.ie/Eiffel/ (Simon Parker, sparker@eiffel.ie)
- Enea Data, http://www.enea.se/ (contact: eiffel@enea.se)
- Everything Eiffel, http://www.eiffel.demon.co.uk/ (Roger Browne, roger@eiffel.tm)
- Information and Math Science Lab Inc, http://www.imslab.co.jp/< (contact: fushimi@imslab.co.jp)
- Eiffel Software, Inc. http://www.eiffel.com/ (contact: info@eiffel.com)
- Langmack & Partner, Feinarbeit, http://www.feinarbeit.de/ (Olaf Langmack, langmack@feinarbeit.de )
- Object Toolds Gmbh,http://www.object-tools.com/ (Frieder Monninger, fm@object-tools.com )
QCNF: y a-t-il des conférences pour des utilisateurs d'Eiffel ?
- TOOLS est (était ?) une conférence internationale consacrée aux applications technologiques objet. Elle est organisée par Eiffel Software et c'est une conférence populaire parmi les utilisateurs d'Eiffel. Les réunions de groupe d'utilisateurs d'EiffelStudio se déroulent en parallèle de cette conférence. http://www.tools-conferences.com/
- La conférence d'ACM SIGPLAN sur la programmation orientée objet (OOPSLA) est probablement la plus grande conférence technique au sujet de la technologie d'OO. http://www.acm.org/sigplan/oopsla/
- ECOOP est la conférence européenne annuelle pour la programmation orientée objet.http://www.ecoop.org
QECC: Pourquoi la plupart des implémentation d'Eiffel génèrent du C ?
En employant C comme langue cible, les développeurs de compilateur Eiffel peuvent:- apporter plus rapidement Eiffel sur le marché et à un moindre coût
- adapter plus facilement leur implémentation sur d'autres plateformes
- tirer profit des optimisations fournies par le compilateur C
La compilation d'Eiffel en C semble fonctionner sans problème sous Unix. C est parfois considéré comme le code natif d'Unix.
Toutefois il y a un certain nombre des compilateurs qui peuvent compiler vers d'autres langages, telles que les machines virtuelles de Java ou .NET, ou en assembleur x86.
QJVM: Où puis-je trouver un compilateur d'Eiffel vers Java ?
Depuis que Java est à la mode, tout le monde veut que leur langage favori soit compilé en JVM (assembleur de la machine virtuelle de Java). Il serait tentant d'essayer de compiler Eiffel en Java et d'offrir une interopérabilité totale entre le code de Java et d'Eiffel.Malheureusement, les choses ne sont pas aussi simples qu'elles le semblent à première vue. Il y a des différences fondamentales entre les modèles objet de Java et d'Eiffel. Parmi les problèmes on peut citer :
- objets dynamiques versus statiques,
- héritage simple versus multiple,
- conception par contrat versus vœu pieu.
Néanmoins, la plupart des fournisseurs de compilateur essayent de fournir un certain support pour le JVM, avec des limitations différentes suivant les fournisseurs et la stratégie d'implémentation choisie.
SmartEiffel est le premier compilateur qui produit un certain résultat utilisable sur JVM. Eiffel Software et les Object Tools ont annoncé faire des efforts en vue de supporter Java.
QNET: Où puis-je trouver un compilateur Eiffel vers .NET ?
La version actuelle du compilateur d'Eiffel Software peut produire du code pour .NET (infrastructure du langage commun de Microsoft). Eiffel Software fait également partie de l'ECMA (association européenne de constructeurs d'ordinateurs) en vue de standardiser le CLI. L'environnement standard aussi bien que l'extension pour Visual Studio (ENVisioN) peuvent être employés pour produire du code .NET.Tandis que les premières versions de .NET ne permettaient d'utiliser qu'un sous-ensemble ad hoc d'Eiffel, la version actuelle permet d'utiliser la totalité du langage. Les fonctions d'Eiffel qui ne sont pas directement implémentées par le modèle d'objet .NET sont implémentées en dehors du noyau.
Problèmes liés au langage :
LFEA: Quelles sont les fonctionnalités d'Eiffel ?
Eiffel est un langage orienté objet pur et statiquement typé. Sa modularité est basée sur les classes. Sa fonctionnalité la plus originale est sûrement la conception par contrat. Elle rapproche la programmation et la conception, et encourage à produire des logiciels plus faciles à maintenir et à produire des composants réutilisables.Eiffel offre les mecanismes suivants:
- classes,
- héritage multiple,
- polymorphisme,
- typage statique avec résolution dynamique,
- généricité (contrainte ou pas),
- un mécanisme d'exceptions disciplinées,
- utilisation systématique des assertions pour promouvoir la conception par contrat.
Une présentation est disponible à : http://www.eiffel.com/doc/manuals/language/intro/
LCHN: Quels changements ont été faits à la définition du langage Eiffel ?
Eiffel est encore un langage relativement nouveau, et il y eu plusieurs changements de sa définition.Il y a eu des changements significatifs entre la publication de Object-Oriented Software Construction, première édition de 1988, et la publication d'Eiffel 2.3.
Des changements plus significatifs correspondent à l'introduction d'Eiffel 3, la version courante du langage utilisée actuellement. Ces changements sont résumés dans le livre Eiffel: The Language .
Il y aussi des changements moins significatifs entre les première et seconde réimpressions d'Eiffel: The Language : de nouveaux types de bases sans aspect 'expanded' (INTEGER_REF, REAL_REF, etc.), un type POINTER pour les références externes, des appels au routines externes ne passant plus implicitement l'objet courant.
Depuis, les changements suivants ont été adoptés et largement implémentés:
- Le mot clé Precursor, qui permet d'appeler la version parente d'une routine redéfinie (voir LPAR).
- Une notation basé sur un mot clé (create) pour la création d'objet, comme alternative à la notation '!!'.
Une copie de travail de cette prochaine édition est accessible sur la page web de Bertrand Meyer: http://www.inf.ethz.ch/~meyer/publications/
LLIB: Quelles bibliothèques sont livrées avec Eiffel ?
Tous les fournisseurs de compilateurs essayent d'être compatible avec les classes de la bibliothèque Eiffel Library Kernel Standard (ELKS).En supplément, de nombreuses bibliothèques sont fournies avec les compilateurs couvrant les structures de données, les interfaces graphiques, l'analyse lexicale et syntaxique, les entrées/sorties, la persistance, le formatage, les interface utilisateur et bien d'autres.
De nombreuses bibliothèques venant d'autres sources sont disponibles, la plupart en logiciel libre. Il y en a trop pour les lister ici, et un bon point de départ est: http://www.cetus-links.org/oo_eiffel_libraries.html
LDBC: Pourquoi tant de remous à propos des preconditions et des postconditions ?
Le point important c'est qu'elles permettent de mettre en œuvre la conception par contrat. Par exemple, les préconditions (clause 'require') sont de simples expressions booléennes qui vérifient que les arguments d'une routine sont valides et que l'objet est dans un état prêt à commencer l'opération requise. Sinon, une exception est générée. De manière similaire, les postconditions (clause 'ensure') permettent de garantir qu'une routine a effectué sa tâche avec succès, de façon à remplir son contrat avec son appelant. Les invariants sont des expressions booléennes qui sont vérifiés à chaque fois qu'une routine d'un objet revient d'un appel initié d'un autre objet.Ces idées peuvent être utilisées dans n'importe quel langage orienté objets, mais d'habitude il faut fournir son propre mécanisme d'assertions, et dépendre de la discipline du programmeur. En Eiffel, ces idées sont intégrées au cœur de l'environnement de programmation. Elles sont utilisées par :
- le mécanisme de gestion d'exceptions.
Les traces d'exceptions peuvent avec plus de précision identifier le code coupable, car les préconditions identifient une erreur de l'appelant, et les postconditions dans la routine elle même. - le système de compilation automatique
Les assertions peuvent être débranchées complètement ou au niveau de chaque classe. - le compilateur Eiffel
Invariants, préconditions et postconditions participent aux relations d'héritages de manière ordonnée. Les expressions des assertions ne sont pas autorisées, par convention, à avoir des effets de bords, ce qui permet de les omettre sans dommages. les outils de génération de documentation.
LCQS: Pourquoi séparer les requêtes des commandes ?
C'est une convention en Eiffel que les fonctions (les routines qui retournent une valeur) ne doivent pas avoir d'effets de bord. Cela signifie que toutes les routines qui changent l'état de leur objet doivent être des procédures, et non pas des fonctions. Si elles retournent un résultat, un attribut annexe peut être utilisé.Par exemple, une classe Eiffel typique qui représente une fonctionnalité de lecture de fichier sera fournie avec une routine pour lire une ligne, qui rendra le résultat disponible séparément. Un client fera donc:
C'est essentiel pour la conception par contrat, car les assertions sont des expressions booléennes qui ne doivent pas changer l'état des objets, sinon le programme ne se comporterait pas de la même manière si les assertions ne sont pas vérifiées.a_file.read_line -- read_line est une procédure
do_something_with (a_file.last_string)
Les effets de bords internes, qui changent l'état concret mais pas l'état abstrait de l'objet et ne sont pas visible de l'extérieur, sont acceptables.
LCON: Qu'elle est la différence entre la covariance et la contravariance ?
Considérons la situation suivante: deux classes, PARENT et ENFANT. ENFANT hérite de PARENT, et redéfinit la fonction toto de PARENT:class PARENT
feature
toto (arg: A) is ...
end
class ENFANT
inherit
PARENT
redefine toto end
feature
toto (arg: B) is ...
end
La question est: quelles sont les restrictions placées sur le
type de l'argument de toto, A et B ? (S'ils sont identiques,
pas de problème.)
Il y a deux possibilités:
- B doit être un descendant de A (la règle covariante - ainsi décrite car l'héritage varie dans la même direction entre la classe et le paramètre. Le paramètre dans le descendant, est un descendant du paramètre dans le parent).
- B doit être un parent de A (la règle contravariante).
Au premier abord, la règle contravariante semble attrayante. Rappelons nous que le polymorphisme signifie qu'un attribut peut référer à non seulement un objet de son type déclaré, mais aussi à un objet de type d'un descendant (enfant). Le schtroumpf dynamique signifie, qu'un appel de fonction sur un objet se fera sur la fonction correspondant au type effectif de l'objet, qui peut être un descendant du type déclaré de l'attribut. Avec la contravariance, il est possible d'assigner un objet de type du descendant à une variable, et tous les appels de fonction fonctionneront toujours puisque le descendant est en mesure de répondre aux appels avec arguments au moins aussi généraux que le type de l'ancêtre. En fait, un descendant est un objet qui est aussi une instance complètement valide de l'objet parent: l'héritage est utilisé pour réaliser le sous-typage.
Cependant, en pratique, il est souvent commode de spécialiser
des hiérarchies simultanément:
class PLOT
feature
add(arg: DATA_SAMPLE) is ...
class PLOT_3D
inherit
PLOT
redefine add end
feature
add(arg: DATA_SAMPLE_3D) is ...
Ceci nécessite la règle covariante, et fonctionne en Eiffel.
Ce serait une erreur, si nous mettions un objet PLOT_3D dans un attribut PLOT et essayions de lui ajouter (add) un DATA_SAMPLE. Cet échec vient du fait que l'héritage à été mis en œuvre afin de réutiliser du code, et non pour du sous-typage, mais nous avons appelé une routine du descendant comme si celui ci était un vrai sous-type. C'est le travail du compilateur de trouver et rejeter ce genre d'erreurs, pour qu'il n'y ait pas d'erreur au moment de l'exécution.
Voila un autre exemple de situation pratique qui suggère une
solution covariante. Les herbivores mangent des plantes. Les vaches sont
des herbivores. L'herbe est une plante. Les vaches mangent de l'herbe mais
pas d'autres plantes.
class HERBIVORE |
class PLANTE |
Ça fait ce que l'on désire. Il faut que le compilateur
nous interdise de mettre une vache dans un objet de type HERBIVORE et de
lui faire manger une autre plante, mais on ne devrait même pas essayer
de toute façon.
Considérons aussi la liste 'regime'. Il n'est pas nécessaire
de la redéfinir dans les classes descendantes, car avec la définition
covariante de l'argument de 'mange', la liste peut contenir tout objet
mangeable, comme l'herbe pour une vache. (Avec une définition contravariante
de l'argument de 'mange', il serait nécessaire de rouvrir la classe
parent pour rendre le type de la liste plus général.)
En bref: les problèmes pratiques sont plus naturellement résolus par des solutions covariantes. Eiffel les gère bien, mais des programmes incorrects peuvent générer des erreurs de type à l'exécution, quand des redéfinitions d'arguments covariantes sont présentes.
LCAT: Il y a t-il vraiment des trous dans le système de type?
Eiffel a été conçu pour qu'il soit possible de détecter les erreurs de type au moment de la compilation et non de lors de l'exécution.Cependant, dans certains cas complexes, il est difficile d'effectuer le contrôle des types. La solution présentée dans Eiffel: The Language , la validité globale au programme, nécessite une analyse globale du programme qui s'est avérée trop complexe et incommode à mettre en œuvre.
Object Oriented Software Construction , deuxième édition, offre une nouvelle méthode qui pourrait, si approfondie, fournir une solution complète. Elle a cependant été remise en question, car elle pourrait s'avérer trop sévère et interdire plusieurs styles de code communément utilisés.
Les principales erreurs de validité au niveau du programme sont:
- la restriction des exports dans une classe descendante
- la redéfinition covariante de paramètres de routines, voir LCON
- les signatures covariantes dues à la conformance des types d'une classe générique (par exemple, 'put' dans LIST[ANY] et LIST[STRING])
- la création de types à ancrage ('like') redéfinis
- des cas plus rares, comme la sélection d'une fonction qui retourne un type précurseur dans une hiérarchie à héritage multiple, ou indirectement l'assignement d'une référence à un ancêtre expanded.
LTSK: Eiffel permet-il d'écrire des applications parallèles?
Eiffel dans ses dernières versions permet le traitement parallèle des données. Le modèle SCOOP (Simple Concurrent Object-Oriented Programming) est décrit dans le chapitre 20 du livre de Bertrand Meyer Object Oriented Software Construction (2nd edition) . Des documents sont disponibles à: http://www.eiffel.com/doc/manuals/technology/concurrency/Plusieurs chercheurs et fournisseurs de compilateurs travaillent actuellement à des implémentations effectives de SCOOP.
En attendant, la plupart des compilateurs sont capables de gérer des formes moins sure de parallélisme, comme le multithreading, indépendamment de SCOOP.
LOVL: Pourquoi Eiffel ne permet-il pas de surcharger les fonctions?
En Eiffel, deux routines ou attributs d'une classe ne peuvent avoir le même nom, indépendamment de leurs signatures respectives. C'est incompatible avec la surcharge de fonction, où plusieurs fonctions du même nom ne sont distinguées que par leur type. C'est une fonctionnalité qui existe dans des langages comme C++.Eiffel a été conçu pour être minimal: il inclut seulement les fonctions que son concepteur a jugé nécessaire, et rien de plus.
Parce qu'Eiffel permet déjà le polymorphisme par le biais de son mécanisme d'héritage, le seul aspect positif de la surcharge de fonction est de réduire le nombre de noms de routines, au prix de réduire la capacité du compilateur à détecter les erreurs de typage.
La lisibilité est aussi améliorée quand la surcharge de fonctions n'est pas permise. Avec celle-ci, le programmeur a besoin de prendre en compte le types des arguments en plus du type de l'objet cible afin de pouvoir déterminer quelle routine sera appelée. Avec l'héritage multiple et le polymorphisme, c'est suffisamment complexe pour un compilateur et prône à confusion pour un dévelopeur.
Cela dit, cette restriction peut forcer à écrire certaines expressions mathématiques de manière inhabituelle. C'est pourquoi certaines expressions arithmétiques de base sont traitées de manière spéciale (voir "arithmetic balancing rule", ETL p.385).
LINC: Pourquoi n'y a t il pas d'opérateur d'incrémentation?
Dans les langages de la famille C, il y a un opérateur pour incrémenter les entiers (++) alors qu'en Eiffel il faut écrire:Un opérateur comme ++ serait une procédure, et changerait donc l'état de son objet. Si les INTEGER d'Eiffel en étaient équipés, ils deviendraient une valeur non constante, et perdraient les avantages qu'ils ont car ils sont constants, comme les autres types numériques. Des types numériques dont la valeur peut changer permettraient aux clients de contourner des éléments de fiabilité du système de typage (les restrictions sur l'affectation des paramètres de fonctions et d'attribut par exemple).un_entier := un_entier + 1
LAGE: Que sont les 'agents' Eiffel ?
Dans les premières versions d'Eiffel, le langage n'avait pas de type autonome pour les routines, car il était jugé que d'avoir ces entités séparées des objets était contraire à la méthode objet.Néanmoins, il est maintenant accepté que les routines comme objets de premier rang sont essentiels et la fonctionnalité des 'agents' a été introduite dans ce but. Elle est implémentée en partie par Eiffel Software et dans SmartEiffel. Les autres fournisseurs actifs suivront probablement.
Bien que cette fonctionnalité soit nouvelle et en cours de standardisation, les concepts centraux, types pour routines, tuples pour les paramètres et le résultat de la routine, sont maintenant au point.
Un agent de base est créé à l'intérieur de l'objet courant, qui fournit un contexte et correspond à une fonctionnalité aussi expressive que les fonctions de premier rang dans les langages de programmation fonctionnelle.
LATR: Pourquoi n'y a t-il pas d'attributs de classe en Eiffel?
En Eiffel les fonctions 'once' fournissent une fonctionnalité plus étendue de manière plus rigoureuse. Le corps d'une fonction est exécuté une seule fois par programme (et non pas par instance de la classe), quand il est appelé pour la première fois. Ensuite, la fonction 'once' retourne le même résultat sans exécuter a nouveau le corps de la fonction.Ces fonctions permettent d'implémenter un attribut partagé de type référence, qui est initialisé la première fois qu'il est utilisé.
Une fonction 'once' peut être incluse dans une classe 'mixin'. L'attribut partagé retourné par cette fonction 'once' est alors disponible pour toutes les instances de classe qui héritent de la classe 'mixin'.
LPAR: Comment appeler l'ancêtre d'une routine redéfinie?
Ceci était un problème qui nécessitait un usage compliqué de l'héritage dans de précédente version d'Eiffel, avant l'introduction du concept Precursor.Ce concept, aujourd'hui implémenté par tous les compilateurs, donc appeler la version parent d'une routine se réduit à l'utilisation du mot clé 'Precursor' à l'intérieur de la redéfinition de la routine.
Ce concept est décrit dans ce document: http://www.eiffel.com/doc/manuals/language/precursor/
LEVC: Où trouve t-on une comparaison entre Eiffel et d'autres langages?
Le livre de Ian Joyner Objects Unencapsulated compare C++, Java et Eiffel et est disponible en librairie (voir QBOK), ou sur Internet: http://burks.brighton.ac.uk/burks/pcinfo/progdocs/cppcrit/Consultez aussi Software Development Using Eiffel: There can be life after C++ de Richard Wiener (voir QBOK).
Il y a aussi une comparaison entre Eiffel, C++, Java et Smalltalk à: http://www.eiffel.com/doc/manuals/technology/oo_comparison/
LDES: Il y a t-il des destructeurs en Eiffel?
Les objets en Eiffel sont gérés par un gestionnaire de mémoire automatique (ramasse miettes), donc il n'y a pas besoin de les libérer à la main.Néanmoins, le besoin peut se faire sentir d'effectuer automatiquement certaines opérations au moment où le gestionnaire de mémoire détruit l'objet.
Par exemple, si un objet correspondant à un fichier devient mort et est prêt à être libéré, il peut être utile de s'assurer que le descripteur de fichier du système d'exploitation sera aussi libéré à ce moment là. La plupart des implémentations du langage fournissent un mécanisme dans ce but: la procédure 'dispose' de la classe MEMORY du Kernel. Chaque fois que le gestionnaire de mémoire libère un objet, il appelle 'dispose' sur cet objet. Cette procédure ne fait rien par défaut. Toute classe peut hériter de MEMORY et redéfinir 'dispose' pour effectuer des actions tels que la fermeture d'un fichier.
Parce qu'il n'est pas possible de garantir l'ordre ou le moment auquel le gestionnaire de mémoire libérera les objets, les redéfinitions de 'dispose' doivent, pour être fiables, ne toucher qu'aux ressources externes, et ne pas toucher des structures d'objets en Eiffel, qui auraient déjà pu être libérées.
LDIS: Comment implémenter au mieux l'héritage multiple?
Ceux qui connaissent le C++ ou les langages à héritage simple pensent souvent que l'héritage multiple est lent parce qu'il ne peut pas être implémenté avec la méthode classique de table de fonctions, où chaque fonction polymorphique a une position fixe dans une table de pointeurs de fonction que les descendants peuvent étendre sans perturber le code qui connaît les positions fixes dans la table du parent.Il y a d'autres manières d'implémenter l'héritage qui permettent aux compilateurs Eiffel de ne pas être pénalisés par l'héritage multiple. Une des deux méthodes suivantes est généralement utilisée.
Dans les deux cas, il est nécessaire de supposer que chaque type dans le système de typage est associé a un identifiant entier unique : l'identifiant de type.
La première implémentation est basée sur un modèle de matrice creuse. Chaque routine ou attribut polymorphique est associé avec une table de pointeurs qui a une entrée pour chaque type, indexée par identifiant de type. Cela permet à tous les appels polymorphiques d'être exécutés avec le même coût : une lecture de pointeur.
L'inconvénient le plus évident, c'est que cela nécessite une grosse table (une matrice de toutes les routines par tous les types du système). Heureusement, il existe des algorithmes de matrices creuses qui permettent de réduire la taille de ces tables en choisissant les identifiants prudemment. Une optimisation évidente est de grouper les descendants auprès de leur parent, de façons à ce que seule une courte section contiguë de l'espace des identifiants soit couverte.
L'autre méthode est complètement différente et utilise l'équivalent du mécanisme 'inspect' sur chaque identifiant de type, en appelant la fonction statique correspondante pour chaque type dynamique concret. Dans ce cas, il est évident que le compilateur a besoin d'une connaissance globale du système: pour chaque appel polymorphique, il faut connaître tous les sous types concrets qui sont effectivement utilisés dans le programme, et ceux qui redéfinissent chaque routine.
Au premier abord, on pourrait penser que ce mécanisme de résolution serait lent. Mais les compilateurs qui implémentent cette solution ont démontré que cela peut être aussi, voire plus, efficace que la première méthode.
Il est maintenant clair que pour ces deux méthodes le compilateur doit avoir une vue complète du système au moment de la compilation, ou au moment de l'optimisation. Cela pourrait sembler être une restriction sévère, mais en fait ce n'est pas un problème sérieux car les compilateurs optimisant en ont déjà besoin, car ils doivent de toute façon différentier entre routines statiques et polymorphiques, toutes les routines pouvant êtres polymorphiques en Eiffel.
LISA: Comment fonctionne l'exemple d'itération multiple d'ETL?
Le programme d'exemple de la page 176 de la version anglaise de Eiffel: The language ne fonctionne avec aucun des compilateurs actuellement disponibles. Il a été source de confusion pour de nombreux débutants et ce qu'il est supposé faire n'est pas clairement défini dans le livre.Il devrait faire la chose suivante: quand une routine est répliquée grâce à l'héritage multiple (avec renommage de manière à ce qu'une routine soit connue sous deux noms différents) et dans la même clause d'héritage une routine ou attribut, que le source de la première routine référence, les deux versions dupliquées de la première routine devraient être différenciées pour appeler la routine ou attribut correspondant à chaque source d'héritage. Ce mécanisme n'est pas fait pour suivre des cas plus complexe où la réplication apparaît dans plusieurs clauses d'héritage.
Cette fonctionnalité est maintenant considérée comme obsolète, car les agents (voir LAGE) sont disponibles, et fournissent une méthode plus commode pour faire la même chose.
LORB: Est-ce que COM/CORBA est supporté?
Aucun support pour COM ou CORBA ne fait partie du langage. La plupart des fournisseurs de compilateurs qui tournent sous Windows ont une bibliothèque COM qui va avec leur compilateur.Il existe une bibliothèque CORBA en logiciel libre: MICO/E, voir http://www.math.uni-goettingen.de/micoe/
2AB, Inc, http://www.2ab.com/, vend une interface entre Eiffel et leur bibliothèque CORBA, qui fonctionne avec ISE Eiffel.
Last generation : 2008-05-10 : 09h 33min 33sec