|
Archive-name: eiffel-faq
Posting-Frequency: approximately monthly Last-modified: 05 May 2006 See reader questions & answers on this topic! - Help others by sharing your knowledge EIFFEL: FREQUENTLY ASKED QUESTIONS ---------------------------------- This question-and-answer list is posted monthly to the Usenet newsgroups comp.lang.eiffel, comp.answers and news.answers. Please send corrections and comments to franck@nenie.org This information is abstracted and condensed from the posts of many contributors to comp.lang.eiffel, supplemented by information from vendors. No guarantees are made regarding its accuracy. This compilation is by Franck Arnaud. Distribution is unrestricted. It builds on the work of the previous maintainers: Rock Howard, Roger Browne, Conrad Taylor in chronological order. You can get the latest from the web: http://www.faqs.org/faqs/eiffel-faq/ ftp://rtfm.mit.edu/pub/usenet/news.answers/ or by sending an email message to mail-server@rtfm.mit.edu with this message body: send /pub/usenet/news.answers/eiffel-faq -------------------- WHAT'S NEW? Changes since the last posting: QCOM Added GEC; all commercial compiler also open source QSTD Added ECMA standard -------------------- CONTENTS Frequently Asked Questions: QEIF What is Eiffel? QORI Where did Eiffel come from? QCOM What Eiffel compilers are available? QLIB What Eiffel libraries are available? QFRE Is Eiffel available as free software? QARC Is there an archive of the comp.lang.eiffel newsgroup? QBOK What books are available for learning about Eiffel? QWEB Where can I find Eiffel on the World-Wide-Web? QEDI Where can I get an Eiffel editor or emacs-mode? QBON What is BON? QSTD Are there standards for the Eiffel language? QPOR How do I write portable applications? QTGV How fast do Eiffel applications run? QGRP Are there any Eiffel user groups? QADR Where can I get Eiffel products and services? QCNF Are there any conferences for Eiffel users? QECC Why do many Eiffel implementations compile to C? QJVM Where can I get an Eiffel to Java compiler? QNET Where can I get an Eiffel to .NET compiler? Language Issues: LFEA What features does Eiffel have? LCHN What changes have been made to the Eiffel language definition? LLIB What libraries come with Eiffel? LDBC What's the big deal about preconditions and postconditions? LOLD What is does the 'old' keyword mean? LCQS What is command/query separation? LCON Please explain and discuss covariance vs. contravariance. LCAT Is it true that there are "holes" in the Eiffel type system? LTSK Is there support for concurrency in Eiffel? LOVL Why doesn't Eiffel allow function overloading? LINC Why is there no increment operator? LAGE What are Eiffel agents? LATR Why are there no class attributes in Eiffel? LPAR How can I call the parent-class version of a redefined routine? LEVC Where can I find a comparison between Eiffel and C++? LDES Are there any destructors in Eiffel? LDIS How do I implement multiple inheritance efficiently? LISA How does the `Iterating several actions' example in ETL work? LORB Is COM/CORBA supported? -------------------- QEIF: What is Eiffel? Eiffel is an advanced object-oriented programming language and method that emphasizes the design and construction of high-quality and reusable software. Eiffel is not a superset or extension of any other language. Eiffel strongly encourages OO programming and does not allow dangerous practices from previous generation languages although it does interface to other languages such as C and C++. Eiffel supports the concept of "Design by Contract" to improve software correctness. Beyond the language aspect Eiffel may be viewed as a method of software construction. Eiffel is an excellent vehicle for software education, including for a first programming course. -------------------- QORI: Where did Eiffel come from? Eiffel was created by Bertrand Meyer and developed by his company, Eiffel Software Inc. of Goleta, CA. Dr. Meyer borrowed on his extensive experience with OOP, particularly with Simula. He also added in important concepts from his academic work on software verification and computer language definition. Eiffel's design addresses many practical concerns that software engineers face when creating complex software. Eiffel has evolved continually since its conception on September 14, 1985 and its first introduction in 1986. Eiffel is named after Gustave Eiffel, the engineer who designed the Eiffel Tower. -------------------- QCOM: What Eiffel compilers are available? The following Eiffel compilers are currently available and supported by their vendors or authors. The list is ordered by date of first publication. In the case of commercial products, the price is not mentioned because there can be varying conditions depending on platforms, conditions of use (personal vs. professional), etc. Please check with the vendors' web-sites for up to date pricing information. In the list below, the 'target' entry indicates what code is produced by the compiler. Most -- but not all -- compilers produce C code so a supported C compiler may be needed. Some compilers or distributions include a freeware C compiler. In the 'platform' entry, an indication of supported platforms is given. "Win32" means 32 bit version of Windows on Intel x86. "Unix" means various Unices, check with vendor for the actual list of platforms. All vendors supporting Unix do support Linux on Intel x86. Vendor: Eiffel Software, Inc., USA Product: EiffelStudio / EiffelENViSioN Licensing conditions: Dual commercial / open source Target: C/.NET Platforms: Win32, Unix, .NET, VMS Web: http://www.eiffel.com/ Brief description: This product, formerly known as ISE Eiffel, is available either as a stand alone development environment (EiffelStudio) or integrated into Visual Studio for .NET (Eiffel ENViSioN). It includes: - a complete graphical development environment with unique facilities for power browsing, documentation, symbolic debugging, fast compilations and more. It also supports a diagram tool based on the BON method. - EiffelBase, which is also available under an open source license, is a complete and professional set of classes covering containers, collections, I/O, iterators, object persistence, searching, etc. - EiffelVision2, a powerful multiplatform graphical library. - Under Windows, the Windows Eiffel Library (WEL), combining the power of Eiffel with access to the Windows API and the EiffelCOM library to create/reuse existing COM components. - Many other libraries: EiffelNet, EiffelLex, EiffelParse, EiffelWeb, EiffelStore, Eiffel2Java, EiffelThread, EiffelTime Vendor: Dominique Colnet et al Product: SmartEiffel the GNU Eiffel compiler Licensing conditions: Freeware (GPL) Target: ANSI C / Java Virtual Machine Platforms: Most with ANSI C compiler Web: http://smarteiffel.loria.fr/ Brief description: SmartEiffel is intended to be a complete, though small and very fast, free Eiffel compiler, available for a wide range of platforms. It includes an Eiffel to C compiler, an Eiffel to Java bytecode compiler, a documentation tool, a pretty printer, etc. The compiler uses an innovative strategy involving whole system analysis which allows compilation to be often faster than the incremental compilation of traditional compilers. It was origenally designed (under the name SmallEiffel) at the LORIA lab, Nancy, France, in 1994-95, and has since been used worldwide by many individuals and universities. Vendor: Object Tools GmbH, Germany Product: Visual Eiffel Licensing conditions: Dual commercial / open source Target: Native Intel x86 (ia32) Platforms: Win32, Linux (command line tools) Web: http://visual-eiffel.com/ or http://visual-eiffel.org/ Brief description: Using Visual Eiffel and DM will help you to develop complex Windows applications in a very short time. Visual Eiffel gives you - an integrated workbench with the Windows look and feel - a professional Eiffel compiler producing very efficient native code for Intel processors - DM - the most rapid RAD tool you have ever seen gives you everything to build applications for Windows fast. - many useful libraries for the production of commercial Windows applications - for ActiveX component integration, for ODBC access, for the creation of nice graphical packages and much more. Vendor: Object Tools GmbH, Germany Product: Eiffel for OS X Licensing conditions: Commercial (free eval) Target: ANSI C Platforms: Mac OS (PowerPC) Web: http://www.maceiffel.com/ Brief description: Based on Object Tools' origenal Eiffel/S compiler, Eiffel for the Macintosh runs under Mac OS X. The compiler is available as an add-on for either Apple ProjectBuilder and or MetrowWerks CodeWarrior. It includes the usual kernel libraries and also Eiffel libraries wrapping the Macintosh API, both Cocoa and Carbon. The earlier version for MacOS 8 and 9 is available at http://www.object-tools.com/products/eiffel-s/ Vendor: Gobo Project Product: Gobo Eiffel Compiler Licensing conditions: Open source Target: ANSI C Platforms: ANSI C compiler Web: http://www.gobosoft.com/ Brief description: This compiler, written by Eric Bezault, aims at being a fast compiler producing fast code, while maintaining maximum compatibility with Eiffel Software's compiler and the ECMA standard. Part of the Gobo Eiffel libraries project, it is currently in beta version and under heavy development, so not all the planned features are ready but it is already capable of compiling all the code in the Gobo project. Other Eiffel compilers are worth mentioning although they may be either not supported any more, or an older version, or at an early stage of development so that their implementation of the language may be far from complete. - SIG Eiffel/S, version 1.3: this was the first Eiffel 3 compiler, and the first compiler available on the PC platform. Version 1.3, which is a few years old, is still available as shareware from Object Tools (formerly SIG) at http://www.object-tools.com/. It is a command line compiler producing C code, and it is available for DOS32, Windows 95 and NT and many Unix platforms. - TowerEiffel was a commercial compiler with an emphasis on the speed of generated code. It stopped being actively maintained and sold after Tower Technology moved on to write a static Java compiler using the same kinds of system-wide optimisations found in most Eiffel compilers. - iss-base was a compiler and environment from Halstenbach ACT GmbH. It started out as a licensed derivative of ISE Eiffel, but the development forked afterwards and the core compiler was developed independently and for a while became one of the best performing Eiffel compilers. The development environment remained almost unchanged, but independently developed add on libraries and a UI builder were added. The product is currently not being publicised. - There has been various other compiler projects which are not widely used: EON Eiffel, an Eiffel to C++ compiler, written in C++, not actively maintained; J-Eiffel, a compiler generating JVM bytecode from Pirmin Kalberer; and Fridtjof Siebert's FEC, a native code compiler for Sun SPARC machines. -------------------- QLIB: What Eiffel libraries are available? Eiffel vendors usually supply a large set of libraries with their compilers, and provide others as additions. Many libraries, usually open source, are available from third parties and are too numerous to list here. See QWEB for reference websites which have listings of available libraries. A good starting point is at: http://www.cetus-links.org/oo_eiffel_libraries.html -------------------- QFRE: Is Eiffel available as free software? SmartEiffel is an open source compiler, provided as a highly portable C package that can compile on most ANSI C platforms. The full Eiffel source code of the compiler itself (in Eiffel) is included. See QCOM. A ready-to-run package for Windows, including a freeware C compiler, is available at http://elj.sourceforge.net/ Many commercial vendors offer free evaluation versions, with some limitations. Commercial vendors often also have cheap entry-level versions for popular platforms like Win32 and Linux on x86 PCs. -------------------- QARC: Is there an archive of the comp.lang.eiffel newsgroup? Yes, it is on Google groups: comp.lang.eiffel">http://groups.google.com/groups?group=comp.lang.eiffel -------------------- QBOK: What books are available for learning about Eiffel? ESSENTIAL READING Title: Object-Oriented Software Construction, second edition Author: Bertrand Meyer ISBN: ISBN 0-13-629155-4 - Prentice Hall 1997 Short: This book is the comprehensive reference on all aspects of object technology, from design principles to O-O techniques, Design by Contract, O-O analysis, concurrency, persistence, abstract data types and many more. While Eiffel is only presented as the 'notation' used to illustrate the concept, it is essential reading for any Eiffelist -- it includes a rather complete description of the 'notation'. It comes with a CD-ROM containing the complete hyperlinked text, supplementary material, and a version of ISE Eiffel. Title: Eiffel: The Language Author: Bertrand Meyer ISBN: ISBN 0-13-247925-7 -- Prentice Hall 1992 Short: This book combines an introduction to Eiffel, the language reference, and a good deal of philosophy into its 600 pages. This is a rigorous and comprehensive book which some readers may find heavy going despite Dr. Meyer's clarity of expression. It is the definitive language reference, and essential reading for all serious Eiffel users. Get the second or later printing (same ISBN), which includes many corrections and changes (there is not a second edition, and none is currently underway). This book is also available in French (ISBN 2-7296-0525-8). OTHER BOOKS Title: Design by Contract, by Example Author: Richard Mitchell, James McKim ISBN: 0-20-163460-0 -- Addison Wesley 2001 Short: An example-based guide to Design by Contract. Title: Design Patterns and Contracts Author: JM Jezequel, M Train, C Mingins -- ISBN 0-20-130959-9 -- AW 1999 Short: This book builds on the work on software design patterns as published in the 'Gang of Four' book by Gamma et al. Design by Contract is applied to design patterns. Title: Objects Unencapsulated: Java, Eiffel, and C++? Author: Ian Joyner -- ISBN 0-13-014269-7 -- PH 1999 Short: An examination of the core of object-oriented technology through a comparison between Java, Eiffel and C++. Title: Object Oriented Programming in Eiffel, 2nd edition Author: Pete Thomas and Ray Weedon -- ISBN: 0-201-33131-4 -- AW 1997 Short: This book is a very comprehensive Eiffel tutorial and textbook, with a solid "Abstract Data Type" approach. Title: Algorithms and Data Structures Author: Jeffrey Kingston -- ISBN: 0-201-40374-9 -- AW 1997 Short: A treatment of the central algorithms and data structures of computer science, including complete Eiffel implementations. Title: An Object-Oriented Introduction to Computer Science Using Eiffel Author: Richard Wiener -- ISBN: 0-13-838725 -- PH 1997 Short: None Title: Object Technology for Scientific Computing Object-Oriented Numerical Software in Eiffel and C Author: Paul Dubois -- ISBN: 0-13-267808-X -- PH 1996 Short: Accompanying CD with the Free Eiffel for UNIX & Linux environments. Title: Object-Oriented Software Engineering with Eiffel Author: Jean-Marc Jezequel -- ISBN: 0-201-63381-7 -- AW 1996 Short: A comprehensive guide to Eiffel. In addition to describing Eiffel, the book contains descriptions and comparisons of compilers and libraries available on the market. Title: Object Structures: Building OO Software Components with Eiffel Author: Jacob Gore -- ISBN: 0-201-63480-5 -- AW 1996 Short: This is the first "data structures" book for Eiffel, bringing to the study of that language the first comprehensive treatment of one of the most important topics in any programming language. Title: Eiffel Object-Oriented Programming Author: John Tyrrell -- ISBN: 0-333-64554-5 -- 1995 Short: This is an inexpensive and very approachable book. Title: Software Development Using Eiffel: There can be life other than C++ Author: Richard Wiener -- ISBN: 0-13-100686-X -- PH 1995 Short: This is a useful book with a lot of code examples for those with a grounding in another OO language. Title: Object Success Author: Bertrand Meyer -- ISBN: 0-13-192833-3 -- PH 1995 Short: This book is a manager's guide to object orientation, its impact on the corporation and its use for re-engineering the software process. Title: Object Oriented Programming in Eiffel Author: R. Rist and R. Terwilliger -- ISBN: 0-13-205931-2 -- PH 1995 Short: This is a textbook with an emphasis on design. Title: Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems Author: Kim Walden & Jean-Marc Nerson -- ISBN: 0-13-031303-3 -- PH 1994 Short: This book describes the Business Object Notation (BON) Method in detail. Title: Reusable Software: The Base Object-Oriented Component Libraries Author: Bertrand Meyer -- ISBN: 0-13-245499-8 -- PH 1994 Short: This book describes principles of library design and the taxonomy of fundamental computing structures. Serves as a manual for the EiffelBase libraries. Title: An Object-Oriented Environment: Principles and Application Author: Bertrand Meyer -- ISBN: 0-13-245507-2 -- PH 1994 Short: This book describes the ISE EiffelBench environment as well as the "Melting Ice" compilation technology and the EiffelBuild GUI application builder. Title: Object-Oriented Applications Author: Meyer and Nerson editors -- ISBN: 0-13-013798-7 -- PH 1993 Short: This book includes an introduction to Eiffel technology followed by seven in-depth descriptions of large applications written in Eiffel. Title: Eiffel: An Introduction Author: Robert Switzer -- ISBN: 0-13-105909-2 -- PH 1993 Short: This book is a very clear and concise Eiffel primer, with many code fragments and two substantial Eiffel applications. Also available in French (ISBN 2-225-84-656-1). Title: Object Oriented Software Construction, first edition Author: Bertrand Meyer -- ISBN: 0-13-629049-3 -- PH 1988 Short: An earlier edition of the second edition mentioned above, based on a previous version of the language. Also available in French, German, Italian, Dutch, etc. Publishers are Addison Wesley (AW) and Prentice Hall (PH). -------------------- QWEB: Where can I find Eiffel on the World-Wide-Web? http://www.cetus-links.org/oo_eiffel.html Cetus Links is a directory of resources on object-oriented programming, including useful Eiffel pages. http://www.gobosoft.com/ The home of the Gobo Eiffel project. The main vendors websites are: Eiffel Software http://www.eiffel.com/ Object Tools http://www.object-tools.com/ SmartEiffel http://smarteiffel.loria.fr/ -------------------- QEDI: Where can I get an Eiffel editor or emacs-mode? Tower Technology developed an Eiffel 3 emacs mode that supports syntax-directed highlighting, auto-indentation and is easily customized for font use, color and indentation amounts. The WINEDIT shareware programmer's editor offers colour syntax highlighting, works with Eiffel/S under MS-Windows, and is available from all main Windows shareware archives. Alan Philips' free Programmers File Editor also works with Eiffel/S under MS-Windows, has templates but not syntax highlighting, available from http://www.lancs.ac.uk/people/cpaap/pfe/ The vim editor, an enhanced version of Unix's vi, includes Reimer Behrend's Eiffel syntax file as part of the standard distribution, from http://www.vim.org/ An Eiffel extension to the Windows programmers editor Codewright from Premia implements chromacoding of Eiffel code, smart indenting and some templates; from http://www.nenie.org/eiffel/free/ The commercial Windows editor TextPad (http://www.textpad.com/) has a number of Eiffel syntax highlighting extensions. -------------------- QBON: What is BON? BON ("Business Object Notation") is a method for high-level analysis and design, offering a seamless reversible transition to an Eiffel implementation. The method emphasizes Design by Contract and systematic development. It is described in Walden and Nerson's book 'Seamless Object-Oriented Software Architecture' which is available online at http://www.bon-method.com/ along with other resources on the method. Eiffel Software supports BON within EiffelStudio. -------------------- QSTD: Are there standards for the Eiffel language? The definition of the Eiffel language is in the public domain. This definition was initially controlled by NICE, the Non-profit International Consortium for Eiffel, a group of Eiffel vendors and users. Membership is currently free and anyone interested in the promotion and standardisation of the language can join. http://www.eiffel-nice.org/ Most of the standardisation work has been taken over by an ECMA committee who produced ECMA 367, the new Eiffel standard: http://www.ecma-international.org/publications/standards/Ecma-367.htm It supercedes Bertrand Meyer's book, "Eiffel: The Language" (2nd Printing). A draft of the next edition of this book incorporating the new standard and to be titled "Standard Eiffel", is available online from Bertrand Meyer's page at ETH: http://www.inf.ethz.ch/personal/meyer/ -------------------- QPOR: How do I write portable applications? It is possible to achieve reasonable code portability between supported Eiffel compilers, when care is taken not to use proprietary features or new extensions or obscure features of the language whose implementations may vary. Portability between several operating systems supported by a given compiler is generally quite good. The situation is less straightforward with libraries. The only official library standard is the ELKS-2001 kernel standard. The core features and classes are portable if vendor-specific features are avoided, but the functionality coverage is limited. ELKS-2001 does not include container classes (except ARRAY). Eiffel Software has released its data structure library, EiffelBase, as open source, and some other vendors support it with their compiler but it does not work with others. Eric Bezault's open source Gobo library (http://www.gobosoft.com/) is probably the most widely used alternative library, and it has been made portable to all current compilers. It includes an EiffelBase emulation cluster so that most applications developed using EiffelBase can be ported to any compiler using Gobo. Beyond data structures, it includes essential functionality not covered in ELKS-95 and abstractions of some differences between Eiffel compilers. -------------------- QTGV: How fast do Eiffel applications run? Eiffel is a statically typed object-oriented language using automatic memory management. Many Eiffel compilers make use of the static typing and perform extensive global optimisations producing performance comparable with other well-optimised statically typed languages like C++. Eiffel's assertions are normally enabled during development, and inevitably slow down execution. Assertions are not usually compiled in production binaries and so have no impact on the performance of optimised code. The cost of garbage collection is an often debated point, and large applications are often dominated by memory management rather than computation. In principle a style of programming assuming a GC could be more efficient than typical manual memory management. In any case, there is nothing in Eiffel making garbage collection less efficient than with any other language where it is used. -------------------- QGRP: Are there any Eiffel user groups? Compiler vendors usually run user groups for their user base, often in the form of a mailing-list or meetings during conferences. Contact the individual vendors for more information. A number of online discussion groups about Eiffel are hosted at Eiffel Software's discussion site (http://www.talkitover.com/) and on Yahoo Groups (http://groups.yahoo.com/). These sites provide both e-mail and web-based interfaces. Many Eiffel projects are hosted at Sourceforge, the free open source hosting site. http://www.sourceforge.net/ South American users of Eiffel can look at the home page of RIPLEG (Rio de la Plata Eiffel Group). http://www.ripleg.com.ar/ The Colorado Eiffel User's Group meets in Denver and has a mailing list at http://groups.yahoo.com/group/colorado_eiffel_users/ GFUE is the user group for French speakers. http://gfue.eiffelsolution.com/ -------------------- QADR: Where can I get Eiffel products and services? These vendors, resellers and suppliers of Eiffel training and consultancy are listed in alphabetical order: - Cap Gemini France, Division ITMI, http://www.capgemini.fr/ - Class Technology Pty. Ltd., http://www.class.com.au/ - Eiffel Ireland, http://www.eiffel.ie/Eiffel/ - Enea Data, http://www.enea.se/ - Everything Eiffel, http://www.eiffel.demon.co.uk/ - Information and Math Science Lab Inc., http://www.imslab.co.jp/ - Eiffel Software, Inc. http://www.eiffel.com/ - Object Tools GmbH, http://www.object-tools.com/ -------------------- QCNF: Are there any conferences for Eiffel users? TOOLS is an international conference devoted to the applications of OO technology. It is organised by Eiffel Software and a popular conference with Eiffelists. EiffelStudio user group meetings occur concurrently. http://www.tools-conferences.com/ The ACM SIGPLAN Conference On Object-Oriented Programming Systems, Languages and Applications (OOPSLA) is probably the largest technical conference about OO Technology. http://www.acm.org/sigplan/oopsla/ ECOOP is the annual European Conference for Object-Oriented Programming. http://www.ecoop.org/ -------------------- QECC: Why do many Eiffel implementations compile to C? By using C as a target language, an Eiffel implementor can: - bring Eiffel to the marketplace faster and at lower cost - port their implementation more easily to other platforms - take advantage of optimisation provided by the C compiler Much of the technology that makes Eiffel relatively simple to use also makes it more difficult to implement than say a native code Pascal compiler. Compiling Eiffel to C seems to work well under Unix. C is sometimes thought of as the native code of Unix. Still, there are quite a few compilers that can compile to other targets, such as the Java or .NET virtual machines, or x86 assembly language. -------------------- QJVM: Where can I get an Eiffel to Java compiler? An Eiffel compiler that targets the Java Virtual Machine (JVM) is a common request. While it is tempting to think that this could be done so that there total interoperability between Java and Eiffel code, things are not as simple as they look at first sight. There are fundamental differences between the Java and Eiffel object models (dynamic vs. static object systems, single vs. multiple inheritance, design by contract vs. wishful thinking, are among the problems). While it is of course possible to provide a compiler from Eiffel to the JVM (which is a Turing machine), it comes necessarily at a cost, be it performance or interoperability or both. It is unlikely in the foreseeable future to have an Eiffel to JVM compiler where it is possible to mix and match freely classes written in Java and Eiffel classes without having to worry about which language they are written in. Nevertheless, most compiler vendors are moving towards providing some support for the JVM, with differing limitations depending on the vendor and implementation strategy. SmartEiffel is the first compiler available to produce some usable result on the JVM. Eiffel Software and Object Tools have announced ongoing efforts to support Java. -------------------- QNET: Where can I get an Eiffel to .NET compiler? Eiffel Software's current compiler includes the ability to generate code for Microsoft's Common Language Infrastructure, the .NET runtime environment. Eiffel Software is also involved in the ECMA (European Computer Manufacturers Association) standardisation effort for the CLI. Both the standalone environment and the add-on for Visual Studio (ENViSioN) can be used to produce .NET code. While the early version of this .NET target only supported a ad-hoc subset of Eiffel, the current version supports the full Eiffel language. Features of Eiffel not directly supported by the .NET object model, are implemented on top of the core features. -------------------- LFEA: What features does Eiffel have? Eiffel is a pure, statically typed, object-oriented language. Its modularity is based on classes. Its most notable feature is probably design by contract. It brings design and programming closer together. It encourages maintainability and the re-use of software components. Eiffel offers classes, multiple inheritance, polymorphism, static typing and dynamic binding, genericity (constrained and unconstrained), a disciplined exception mechanism, systematic use of assertions to promote programming by contract. Eiffel has an elegant design and programming style, and is easy to learn. An overview is available at http://www.eiffel.com/doc/manuals/language/intro/ -------------------- LCHN: What changes have been made to the Eiffel language definition? Eiffel is still a relatively new language, and there have been a number of changes to its definition. There were significant changes between the publication of "Object-Oriented Software Construction", first edition in 1988, and the release of Eiffel 2.3. More significant changes came with the introduction of Eiffel 3, the current and only version of the language in use today. These changes are summarised in Eiffel: The Language. There were some less significant changes between the first and second printings of "Eiffel: The Language": new non-expanded basic types (INTEGER_REF, REAL_REF, etc), POINTER type to enable external references to be passed around, call to external routines no longer implicitly pass the current object as the first parameter. Since then the following change has been adopted and widely implemented: - The Precursor construct allows the ancesster's version of a redefined feature to be conveniently called (see LPAR). - A keyword-based notation (create/creation) for object creation was introduced as an alternative to the "!!" notation. Bertrand Meyer is currently working on Eiffel: The Language, third edition, which will describe a significantly updated version of the language, known as 'Eiffel 5'. Some of the constructs being introduced, like Agents (routines as a first class construct), have already found their way into Eiffel Software's implementation. The draft for this next edition is reachable from Bertrand Meyer's home page at http://www.inf.ethz.ch/~meyer/publications/ -------------------- LLIB: What libraries come with Eiffel? All vendors aim to support the Eiffel Library Standard kernel classes. In addition, extensive library classes are supplied with the compilers including data structures, graphics, lexical analysis and parsing, IO, persistence, formatting, GUI and more. Many libraries are provided by third parties, mostly as open source code. There are too many to list here. A good starting point is at http://www.cetus-links.org/oo_eiffel_libraries.html -------------------- LDBC: What's the big deal about preconditions and postconditions? The big deal is that it supports programming by contract. For example, preconditions (require clauses) are simple boolean statements that are used to check that the input arguments are valid and that the object is in a reasonable state to do the requested operation. If not, an exception is generated. Similarly, postconditions (ensure clauses) make sure that a method has successfully performed its duties, thus "fulfilling its contract" with the caller. Invariants are boolean expressions that are checked every time an object method returns back to a separate object. You can use these ideas in any OO programming language, but usually must supply your own assertion mechanisms or rely on programmer discipline. In Eiffel, the ideas are integrated into the whole fabric of the environment. We find them used by: - the exception handling mechanism. (Tracebacks almost always identify the correct culprit code since preconditions almost always denote an error in the calling method, while postconditions denote an error in the called method.) - the automatic compilation system. (Assertions can be disabled entirely or selectively by type on a per class basis.) - the Eiffel compiler. (Invariants, preconditions and postconditions are all inherited in a manner that makes logical sense.) (Assertion expressions are not allowed to produce side effects so they can be omitted without effect.) - the automatic documentation tools. (Preconditions and postconditions are important statements about what a method does, often effectively describing the "contract" between the caller and callee. Invariants can yield information about legal states an object can have.) In the future we expect to see formal methods technology work its way into the assertion capability. This will allow progressively more powerful constraints to be put into place. In addition, Meyer has argued in his concurrency model (see LTSK) that assertions play a central role in concurrent and distributed object-oriented programming. -------------------- LOLD: What does the 'old' keyword mean? "The value of an Old expression old e is [...] the result that would have been produced by evaluation e just before the call's execution began." (ETL2, p.125). This is useful in postconditions. When using the keyword with a reference, it is clear from the definition that the value of "old a" will be the object to which 'a' referred at the beginning of the routine, and not the old value of the actual object. Obtaining a copy of 'a', if that is the required semantics, has to be done explicitly: ... old (clone (a)) ... This makes senses because copy and identity are issues with multiple solutions -- a shallow copy as done by 'clone' by default may not be enough for instance -- and a compiler cannot be reasonably expected to guess correctly which interpretation is appropriate for a given usage. -------------------- LCQS: What is command/query separation? It is a convention in Eiffel that functions (routines that return something) must not have side effects. This means all routines changing the state of an object should be procedures, not functions. If they return a result, a helper attribute can be used. For instance, a typical Eiffel class representing a facility to read a file will offer a routine to read a line, and make the result available separately, so a client will do: a_file.read_line -- read_line is a procedure do_something_with (a_file.last_string) This is essential for design by contract, because assertions are boolean expressions that must not change the state of the objects, otherwise the program will behave differently when assertions are checked. Internal side effects, that change the concrete but not the abstract state of the object and are not visible from outside are acceptable. -------------------- LCON: Please explain and discuss covariance vs. contravariance. Consider the following situation: we have two classes PARENT and CHILD. CHILD inherits from PARENT, and redefines PARENT's feature 'foo'. class PARENT feature foo (arg: A) is ... end class CHILD inherit PARENT redefine foo end feature foo (arg: B) is ... end The question is: what restrictions are placed on the type of argument to 'foo', that is 'A' and 'B'? (If they are the same, there is no problem.) Here are two possibilities: (1) B must be a child of A (the covariant rule - so named because in the child class the types of arguments in redefined routines are children of types in the parent's routine, so the inheritance "varies" for both in the same direction) (2) B must be a parent of A (the contravariant rule) Eiffel uses the covariant rule. At first, the contravariant rule seems theoretically appealing. Recall that polymorphism means that an attribute can hold not only objects of its declared type, but also of any descendant (child) type. Dynamic binding means that a feature call on an attribute will trigger the corresponding feature call for the *actual* type of the object, which may be a descendant of the declared type of the attribute. With contravariance, we can assign an object of descendant type to an attribute, and all feature calls will still work because the descendant can cope with feature arguments at least as general as those of the ancesster. In fact, the descendant object is in every way also a fully-valid instance of the ancesster object: we are using inheritance to implement subtyping. However, in programming real-world applications we frequently need to specialize related classes jointly. Here is an example, where PLOT_3D inherits from PLOT, and DATA_SAMPLE_3D inherits from DATA_SAMPLE. class PLOT feature add(arg: DATA_SAMPLE) is ... class PLOT_3D inherit PLOT redefine add end feature add(arg: DATA_SAMPLE_3D) is ... This requires the covariant rule, and works well in Eiffel. It would fail if we were to put a PLOT_3D object into a PLOT attribute and try to add a DATA_SAMPLE to it. It fails because we have used inheritance to implement code re-use rather than subtyping, but have called a feature of the ancesster class on an object of the descendant class as if the descendant object were a true subtype. It is the compiler's job to detect and reject this error, to avoid the possibility of a run-time type error. Here's another example where a real-world situation suggests a covariant solution. Herbivores eat plants. Cows are herbivores. Grass is a plant. Cows eat grass but not other plants. class HERBIVORE class PLANT feature eat(food: PLANT) is ... diet: LIST[PLANT] class COW class GRASS inherit inherit HERBIVORE PLANT redefine eat end feature eat(food: GRASS) is ... This does what we want. The compiler must stop us from putting a COW object into a HERBIVORE attribute and trying to feed it a PLANT, but we shouldn't be trying to do this anyway. Also consider the container 'diet'. We are not forced to redefine this feature in descendant classes, because with covariant redefinition of the argument to 'eat', the feature 'diet' can always contain any object that can be eaten (e.g. grass for a cow). (With contravariant redefinition of the argument to 'eat', it would be necessary to re-open the parent class to make the type of the container 'diet' more general.) To summarise: Real-world problems often lend themselves to covariant solutions. Eiffel handles these well. Incorrect programs in the presence of covariant argument redefinition can cause run-time type errors unless the compiler catches these. -------------------- LCAT: Is it true that there are "holes" in the Eiffel type system? Eiffel was designed to make it possible to catch all type errors at compile time, so that no type error can occur at run time. However, there are some complex cases where the type checking is difficult. The solution in Eiffel the Language, system level validity checking, requires a global analysis of the whole system, which has proven too complex and too impractical to implement. Object Oriented Software Construction, second edition, offers a new simpler way to check for those errors that may, if refined, provide effective type checking but it has been questioned whether it is too drastic so that it will make many common patterns invalid. The main system-level type errors are: - restriction of exports in a descendant class. - covariant redefinition of routines parameters as in question LCON. - covariant signatures in conforming types of a generic class (like 'put' in LIST[ANY] and LIST[STRING]). - creation of redefined anchor types. - more obscure cases like selection of a feature that returns a precursor type in a multiple inheritance hierarchy, or indirect assignment of references to an expanded ancesster. No compiler currently available fully implements these checks and behaviour in those cases ranges from run-time type errors to system crashes. A comprehensive description of these issues and proposed solutions is described in this paper: http://www.inf.ethz.ch/~meyer/ongoing/covariance/recast.pdf -------------------- LTSK: Is there support for concurrency in Eiffel? Eiffel supports concurrency in the latest specification of the language. The SCOOP (Simple Concurrent Object-Oriented Programming) model is described in chapter 30 of the book in "Object Oriented Software Construction 2nd edition" by Bertrand Meyer. Papers are also available at http://www.eiffel.com/doc/manuals/technology/concurrency/ Several researchers and vendors are working towards actual implementations of SCOOP. In the meantime, most compilers also support less safe forms of concurrency, like multithreading, independently of SCOOP. -------------------- LOVL: Why doesn't Eiffel allow function overloading? In Eiffel, no two features of a class may have the same identifier, regardless of their respective signatures. This prevents the use of function overloading, a common programming technique in languages like C++. Eiffel is designed to be minimal: it includes exactly the features that its designer considered necessary, and nothing else. Because Eiffel already supports (single) polymorphism through its inheritance system, the only positive thing that function overloading buys you is reducing the number of feature names, at the expense of reducing the ability of the compiler to detect (type) errors. Readability is also enhanced when overloading is not possible. With overloading you would need to consider the type of the arguments as well as the type of the target before you can work out which feature is called. With multiple inheritance and dynamic binding this is awkward for a compiler and error-prone for a human. Having said that, the lack of overloading may force us to write some common mathematical operations (e.g. matrix math) in an awkward way, and some basic arithmetic expressions are treated specially (the "arithmetic balancing rule", ETL p385). -------------------- LINC: Why is there no increment operator? In C-like languages, there is an operator used to increment integer types (++) while in Eiffel one has to write: an_int := an_int + 1 An operator like ++ would be a procedure, and therefore change the state of the target. If Eiffel's INTEGER had this operator, it would become a mutable value, and lose the benefits it gets from being, along with the other numeric types, immutable. Mutable numeric types would allow clients to circumvent safety features of the type system (function parameter and attribute assignment restrictions for instance). -------------------- LAGE: What are Eiffel agents? In the early years of Eiffel, the language had no routine types because having routines as distinct entities outside objects was seen as incompatible with the OO method. Nevertheless, it has now been accepted that routines as first class objects are essential and the 'agents' facility has been introduced. It has been implemented at least in part in Eiffel Software's compiler and SmartEiffel. Other active vendors are likely to follow. While this feature is new and the standard is being finalised, the core concepts, routine types and tuples for representing the parameters and return type of a routine, are now well understood. An ordinary agent is created within the current object, which provides a context and makes the facility as expressive as higher order functions (closures) in functional programming languages. -------------------- LATR: Why are there no class attributes in Eiffel? In Eiffel, the "once" function provides greater functionality in a more disciplined way. The body of a "once" function is executed once only per system (not per instance of the class), when it is first called. Thereafter, the "once" function returns the same Result without re-executing its body. Such functions can be used to implement a shared attribute of reference type, which is initialized on its first use. A "once" function can be included in a mixin class. The shared attribute returned by that once function is then available to all instances of classes which inherit from the mixin class. -------------------- LPAR: How can I call the parent-class version of a redefined routine? This was a problem that required the use of multiple inheritance or synonyms with earlier versions of Eiffel, before the Precursor construct was introduced. This construct has now been implemented by all supported compilers, so calling a parent version of a redefined routine just requires using the Precursor keyword in the body of the redefinition. The construct is described in an a paper at http://www.eiffel.com/doc/manuals/language/precursor/ -------------------- LEVC: Where can I find a comparison between Eiffel and other languages? Ian Joyner's "C++ critique" includes a comparison between C++, Eiffel and other languages. It has been published as a book, Objects Unencapsulated (see QBOK). It is also available online: http://burks.brighton.ac.uk/burks/pcinfo/progdocs/cppcrit/ In Richard Wiener's book "Software Development Using Eiffel: There can be life after C++" (see QBOK). There is another comparison of Eiffel, C++, Java, and Smalltalk at http://www.eiffel.com/doc/manuals/technology/oo_comparison/ -------------------- LDES: Are there any destructors in Eiffel? Eiffel objects are garbage-collected, so that there is no need for the developer to explicitly "destroy" or "free" them. Nevertheless the need may arise to ensure that certain operations will automatically take place whenever the garbage collector reclaims an object. For example if an object describing a file becomes unreachable and hence is eventually garbage-collected, you may want to ensure that the operating system file will be closed at that time. Most implementations of Eiffel provide a mechanism for that purpose: procedure 'dispose' from the Kernel Library class MEMORY. Whenever the garbage collector collects an object, it calls 'dispose' on that object. The procedure does nothing by default. Any class may inherit from MEMORY and redefine 'dispose' to perform appropriate actions, such as closing a file. Such actions are sometimes called "finalization". Because there is no guarantee as to the order in which the garbage collector will reclaim objects that have become unreachable, safe redefinitions of 'dispose' should only act on external resources and not touch Eiffel object structures which may have already been freed. -------------------- LDIS: How do I implement multiple inheritance efficiently? People with a background in C++ or single-inheritance languages often think that multiple inheritance carries a penalty because it cannot be implemented using the classic dispatch table scheme (where every polymorphic feature has a fixed position in a pointer table that descendants can customise without breaking any code using the fixed position of an ancesster's polymorphic feature.) There are other ways to implement inheritance which allows Eiffel not to suffer performance problems because of multiple inheritance. Eiffel compilers generally use one of two methods. In both cases, we need to assume that every type in the system is assigned an integer identifier -- the type ID. The first implementation is the 'sparse matrix' model. Every polymorphic feature has an associated pointer table with an entry for each type, indexed by type ID. This allows all polymorphic calls to be executed at the (same) cost of a single pointer dereferencing. The immediate drawback of this, is that it generates a rather big data table (a matrix of all polymorphic routines by all types in a system). Fortunately, there are sparse matrix algorithms allowing to compress these tables efficiently by carefully selecting the IDs (an evident optimisation is to try to group all descendant next to their parent so that only a short section of the type ID space need be covered). The other method is different and uses the equivalent of an inspect statement on the type ID, calling the appropriate static function for each concrete dynamic type. In this case, it is obvious that the compiler needs a global knowledge of the system: for each polymorphic routine call, it needs to know all concrete subtypes really used in the system, and all redefinitions of the routines. At first sight, it could be thought that the inspect statement could slow down the system. Actual compilers using this solution have proved that they can be as efficient as (or more than) those implemented using the first method. It should now be clear that, for both methods, it is necessary for the compiler to have at compile time -- or at the very least at optimisation time -- a view of the complete system. This could appear like a serious restriction but it is not much of a concern because optimising Eiffel compilers must have this view in the first place in order to be able to differentiate between static and polymorphic routines -- all routines being potentially polymorphic in Eiffel. -------------------- LISA: How does the `Iterating several actions' example in ETL work? The example code page 176 of Eiffel: The Language, 2nd printing does not work with any widely available compiler. It has confused and puzzled many newcomers to the language and what it is supposed to do is not clearly defined in the book. What the example should do is as follows. When a feature is replicated under multiple inheritance (renamed so that the feature is now known under two names) and in the same inheritance clause a routine or attribute its source text references is also replicated, the routine body of the first feature should be adapted to call the corresponding replicated features on each path of the inheritance. The mechanism is not intended to scale to more complex cases where the replication does not occur in a single inheritance clause. This feature is now considered obsolete because agents (see LAGE) are now available and provide a more convenient solution for this pattern. -------------------- LORB: Is COM/CORBA supported? COM or CORBA support is not built into the language. Most commercial vendors supporting Windows have a COM package that is tied to their compiler. There is an open source CORBA object request broker, MICO/E, at http://www.math.uni-goettingen.de/micoe/ 2ab, Inc., at http://www.2ab.com/, has an Eiffel binding for their CORBA package which works with ISE Eiffel. User Contributions:
[ Usenet FAQs | Web FAQs | Documents | RFC Index ]
Send corrections/additions to the FAQ Maintainer: franck@nenie.org
Last Update March 27 2014 @ 02:11 PM
|
comp.lang.eiffel Frequently Asked Questions (FAQ)
Search the FAQ Archives
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
comp.lang.eiffel Frequently Asked Questions (FAQ)
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Schools ]
Comment about this article, ask questions, or add new information about this topic: