home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / eiffel-faq < prev    next >
Internet Message Format  |  2007-10-08  |  53KB
  1. Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
  2. Message-ID: <eiffel-faq_1191730829@rtfm.mit.edu>
  3. Supersedes: <eiffel-faq_1189052518@rtfm.mit.edu>
  4. Expires: 20 Nov 2007 04:20:29 GMT
  5. X-Last-Updated: 2006/05/10
  6. From: "Franck Arnaud" <franck@nenie.org>
  7. Subject: comp.lang.eiffel Frequently Asked Questions (FAQ)
  8. Newsgroups: comp.lang.eiffel,comp.answers,news.answers
  9. Approved: news-answers-request@mit.edu
  10. Followup-To: comp.lang.eiffel
  11. Reply-To: franck@nenie.org
  12. Organization: not
  13. Originator: faqserv@penguin-lust.mit.edu
  14. Date: 07 Oct 2007 04:22:13 GMT
  15. Lines: 1282
  16. NNTP-Posting-Host: penguin-lust.mit.edu
  17. X-Trace: 1191730933 senator-bedfellow.mit.edu 485 18.181.0.29
  18. Xref: senator-bedfellow.mit.edu comp.lang.eiffel:56506 comp.answers:65182 news.answers:316021
  19.  
  20. Archive-name: eiffel-faq
  21. Posting-Frequency: approximately monthly
  22. Last-modified: 05 May 2006
  23.  
  24.  EIFFEL: FREQUENTLY ASKED QUESTIONS
  25.  ----------------------------------
  26.  
  27. This question-and-answer list is posted monthly to the Usenet
  28. newsgroups comp.lang.eiffel, comp.answers and news.answers.
  29.  
  30. Please send corrections and comments to franck@nenie.org
  31.  
  32. This information is abstracted and condensed from the posts of many
  33. contributors to comp.lang.eiffel, supplemented by information from
  34. vendors. No guarantees are made regarding its accuracy.
  35.  
  36. This compilation is by Franck Arnaud. Distribution is unrestricted.
  37. It builds on the work of the previous maintainers: Rock Howard,
  38. Roger Browne, Conrad Taylor in chronological order.
  39.  
  40. You can get the latest from the web:
  41.  
  42.    http://www.faqs.org/faqs/eiffel-faq/
  43.    ftp://rtfm.mit.edu/pub/usenet/news.answers/eiffel-faq
  44.  
  45. or by sending an email message to mail-server@rtfm.mit.edu with this
  46. message body:
  47.  
  48.    send /pub/usenet/news.answers/eiffel-faq
  49.  
  50.  --------------------
  51.  
  52. WHAT'S NEW?
  53.  
  54. Changes since the last posting:
  55.  
  56.    QCOM  Added GEC; all commercial compiler also open source
  57.    QSTD  Added ECMA standard
  58.    
  59.  --------------------
  60.  
  61. CONTENTS
  62.  
  63. Frequently Asked Questions:
  64.  
  65.    QEIF  What is Eiffel?
  66.    QORI  Where did Eiffel come from?
  67.    QCOM  What Eiffel compilers are available?
  68.    QLIB  What Eiffel libraries are available?
  69.    QFRE  Is Eiffel available as free software?
  70.    QARC  Is there an archive of the comp.lang.eiffel newsgroup?
  71.    QBOK  What books are available for learning about Eiffel?
  72.    QWEB  Where can I find Eiffel on the World-Wide-Web?
  73.    QEDI  Where can I get an Eiffel editor or emacs-mode?
  74.    QBON  What is BON?
  75.    QSTD  Are there standards for the Eiffel language?
  76.    QPOR  How do I write portable applications?
  77.    QTGV  How fast do Eiffel applications run?
  78.    QGRP  Are there any Eiffel user groups?
  79.    QADR  Where can I get Eiffel products and services?
  80.    QCNF  Are there any conferences for Eiffel users?
  81.    QECC  Why do many Eiffel implementations compile to C?
  82.    QJVM  Where can I get an Eiffel to Java compiler?
  83.    QNET  Where can I get an Eiffel to .NET compiler?
  84.  
  85. Language Issues:
  86.  
  87.    LFEA  What features does Eiffel have?
  88.    LCHN  What changes have been made to the Eiffel language definition?
  89.    LLIB  What libraries come with Eiffel?
  90.    LDBC  What's the big deal about preconditions and postconditions?
  91.    LOLD  What is does the 'old' keyword mean?
  92.    LCQS  What is command/query separation?
  93.    LCON  Please explain and discuss covariance vs. contravariance.
  94.    LCAT  Is it true that there are "holes" in the Eiffel type system?
  95.    LTSK  Is there support for concurrency in Eiffel?
  96.    LOVL  Why doesn't Eiffel allow function overloading?
  97.    LINC  Why is there no increment operator?
  98.    LAGE  What are Eiffel agents?
  99.    LATR  Why are there no class attributes in Eiffel?
  100.    LPAR  How can I call the parent-class version of a redefined
  101.          routine?
  102.    LEVC  Where can I find a comparison between Eiffel and C++?
  103.    LDES  Are there any destructors in Eiffel?
  104.    LDIS  How do I implement multiple inheritance efficiently?
  105.    LISA  How does the `Iterating several actions' example in ETL work?
  106.    LORB  Is COM/CORBA supported?
  107.  
  108.  --------------------
  109.  
  110. QEIF: What is Eiffel?
  111.  
  112. Eiffel is an advanced object-oriented programming language and 
  113. method that emphasizes the design and construction of high-quality
  114. and reusable software.
  115.  
  116. Eiffel is not a superset or extension of any other language. Eiffel
  117. strongly encourages OO programming and does not allow dangerous
  118. practices from previous generation languages although it does
  119. interface to other languages such as C and C++. Eiffel supports the
  120. concept of "Design by Contract" to improve software correctness.
  121.  
  122. Beyond the language aspect Eiffel may be viewed as a method of
  123. software construction. Eiffel is an excellent vehicle for software
  124. education, including for a first programming course.
  125.  
  126.  --------------------
  127.  
  128. QORI: Where did Eiffel come from?
  129.  
  130. Eiffel was created by Bertrand Meyer and developed by his company,
  131. Eiffel Software Inc. of Goleta, CA.
  132.  
  133. Dr. Meyer borrowed on his extensive experience with OOP, particularly
  134. with Simula. He also added in important concepts from his academic
  135. work on software verification and computer language definition.
  136.  
  137. Eiffel's design addresses many practical concerns that software
  138. engineers face when creating complex software. Eiffel has evolved
  139. continually since its conception on September 14, 1985 and its first
  140. introduction in 1986.
  141.  
  142. Eiffel is named after Gustave Eiffel, the engineer who designed the
  143. Eiffel Tower.
  144.  
  145.  --------------------
  146.  
  147. QCOM: What Eiffel compilers are available?
  148.  
  149. The following Eiffel compilers are currently available and supported
  150. by their vendors or authors. The list is ordered by date of first
  151. publication.
  152.  
  153. In the case of commercial products, the price is not mentioned because
  154. there can be varying conditions depending on platforms, conditions of
  155. use (personal vs. professional), etc. Please check with the vendors'
  156. web-sites for up to date pricing information.
  157.  
  158. In the list below, the 'target' entry indicates what code is produced
  159. by the compiler. Most -- but not all -- compilers produce C code so a
  160. supported C compiler may be needed. Some compilers or distributions
  161. include a freeware C compiler.
  162.  
  163. In the 'platform' entry, an indication of supported platforms is given.
  164. "Win32" means 32 bit version of Windows on Intel x86. "Unix" means
  165. various Unices, check with vendor for the actual list of platforms.
  166. All vendors supporting Unix do support Linux on Intel x86.
  167.  
  168.  Vendor: Eiffel Software, Inc., USA
  169.  Product: EiffelStudio / EiffelENViSioN
  170.  Licensing conditions: Dual commercial / open source
  171.  Target: C/.NET
  172.  Platforms: Win32, Unix, .NET, VMS
  173.  Web: http://www.eiffel.com/
  174.  
  175.  Brief description:
  176.   This product, formerly known as ISE Eiffel, is available either as
  177.   a stand alone development environment (EiffelStudio) or integrated
  178.   into Visual Studio for .NET (Eiffel ENViSioN). It includes:
  179.   - a complete graphical development environment with
  180.     unique facilities for power browsing, documentation, symbolic
  181.     debugging, fast compilations and more. It also supports a diagram
  182.     tool based on the BON method.
  183.   - EiffelBase, which is also available under an open source license,
  184.     is a complete and professional set of classes covering containers,
  185.     collections, I/O, iterators, object persistence, searching, etc.
  186.   - EiffelVision2, a powerful multiplatform graphical library.
  187.   - Under Windows, the Windows Eiffel Library (WEL), combining the
  188.     power of Eiffel with access to the Windows API and the EiffelCOM
  189.     library to create/reuse existing COM components.
  190.   - Many other libraries: EiffelNet, EiffelLex, EiffelParse, EiffelWeb,
  191.     EiffelStore, Eiffel2Java, EiffelThread, EiffelTime
  192.  
  193.  
  194.  Vendor: Dominique Colnet et al
  195.  Product: SmartEiffel the GNU Eiffel compiler
  196.  Licensing conditions: Freeware (GPL)
  197.  Target: ANSI C / Java Virtual Machine
  198.  Platforms: Most with ANSI C compiler
  199.  Web: http://smarteiffel.loria.fr/
  200.  
  201.  Brief description:
  202.   SmartEiffel is intended to be a complete, though small and very fast,
  203.   free Eiffel compiler, available for a wide range of platforms.
  204.   It includes an Eiffel to C compiler, an Eiffel to Java bytecode
  205.   compiler, a documentation tool, a pretty printer, etc.
  206.   The compiler uses an innovative strategy involving whole system
  207.   analysis which allows compilation to be often faster than the
  208.   incremental compilation of traditional compilers.
  209.   It was originally designed (under the name SmallEiffel) at the
  210.   LORIA lab, Nancy, France, in 1994-95, and has since been used
  211.   worldwide by many individuals and universities.
  212.  
  213.  
  214.  Vendor: Object Tools GmbH, Germany
  215.  Product: Visual Eiffel
  216.  Licensing conditions: Dual commercial / open source
  217.  Target: Native Intel x86 (ia32)
  218.  Platforms: Win32, Linux (command line tools)
  219.  Web: http://visual-eiffel.com/ or http://visual-eiffel.org/
  220.  
  221.  Brief description:
  222.   Using Visual Eiffel and DM will help you to develop complex Windows
  223.   applications in a very short time. Visual Eiffel gives you
  224.   - an integrated workbench with the Windows look and feel
  225.   - a professional Eiffel compiler producing very efficient native
  226.     code for Intel processors
  227.   - DM - the most rapid RAD tool you have ever seen gives you
  228.     everything to build applications for Windows fast.
  229.   - many useful libraries for the production of commercial Windows
  230.     applications - for ActiveX component integration, for ODBC access,
  231.     for the creation of nice graphical packages and much more.
  232.  
  233.  
  234.  Vendor: Object Tools GmbH, Germany
  235.  Product: Eiffel for OS X 
  236.  Licensing conditions: Commercial (free eval)
  237.  Target: ANSI C
  238.  Platforms: Mac OS (PowerPC)
  239.  Web: http://www.maceiffel.com/
  240.  
  241.  Brief description:
  242.   Based on Object Tools' original Eiffel/S compiler, Eiffel
  243.   for the Macintosh runs under Mac OS X.
  244.   The compiler is available as an add-on for either Apple
  245.   ProjectBuilder and or MetrowWerks CodeWarrior.
  246.   It includes the usual kernel libraries and also Eiffel
  247.   libraries wrapping the Macintosh API, both Cocoa and Carbon.
  248.   The earlier version for MacOS 8 and 9 is available at
  249.   http://www.object-tools.com/products/eiffel-s/
  250.  
  251.  Vendor: Gobo Project
  252.  Product: Gobo Eiffel Compiler
  253.  Licensing conditions: Open source
  254.  Target: ANSI C
  255.  Platforms: ANSI C compiler
  256.  Web: http://www.gobosoft.com/
  257.  
  258.  Brief description:
  259.   This compiler, written by Eric Bezault, aims at being a 
  260.   fast compiler producing fast code, while maintaining 
  261.   maximum compatibility with Eiffel Software's compiler 
  262.   and the ECMA standard.
  263.   Part of the Gobo Eiffel libraries project, it is 
  264.   currently in beta version and under heavy development, 
  265.   so not all the planned features are ready but it is 
  266.   already capable of compiling all the code in the Gobo 
  267.   project.
  268.  
  269. Other Eiffel compilers are worth mentioning although they may be
  270. either not supported any more, or an older version, or at an early
  271. stage of development so that their implementation of the language
  272. may be far from complete.
  273.  
  274.  
  275.  - SIG Eiffel/S, version 1.3: this was the first Eiffel 3 compiler,
  276.    and the first compiler available on the PC platform. Version 1.3,
  277.    which is a few years old, is still available as shareware from Object
  278.    Tools (formerly SIG) at http://www.object-tools.com/.
  279.    It is a command line compiler producing C code, and it is available
  280.    for DOS32, Windows 95 and NT and many Unix platforms.
  281.  
  282.  - TowerEiffel was a commercial compiler with an emphasis on the speed
  283.    of generated code. It stopped being actively maintained and sold after
  284.    Tower Technology moved on to write a static Java compiler using the
  285.    same kinds of system-wide optimisations found in most Eiffel compilers.
  286.  
  287.  - iss-base was a compiler and environment from Halstenbach ACT GmbH.
  288.    It started out as a licensed derivative of ISE Eiffel, but the
  289.    development forked afterwards and the core compiler was developed
  290.    independently and for a while became one of the best performing
  291.    Eiffel compilers. The development environment remained almost
  292.    unchanged, but independently developed add on libraries and a UI
  293.    builder were added. The product is currently not being publicised.
  294.  
  295.  - There has been various other compiler projects which are not widely
  296.    used: EON Eiffel, an Eiffel to C++ compiler, written
  297.    in C++, not actively maintained; J-Eiffel, a compiler generating
  298.    JVM bytecode from Pirmin Kalberer; and Fridtjof Siebert's FEC, a
  299.    native code compiler for Sun SPARC machines.
  300.  
  301.  --------------------
  302.  
  303. QLIB: What Eiffel libraries are available?
  304.  
  305. Eiffel vendors usually supply a large set of libraries with their
  306. compilers, and provide others as additions.
  307.  
  308. Many libraries, usually open source, are available from third
  309. parties and are too numerous to list here. See QWEB for reference
  310. websites which have listings of available libraries. A good
  311. starting point is at:
  312.  
  313. http://www.cetus-links.org/oo_eiffel_libraries.html
  314.  
  315.  --------------------
  316.  
  317. QFRE: Is Eiffel available as free software?
  318.  
  319. SmartEiffel is an open source compiler, provided as a highly
  320. portable C package that can compile on most ANSI C platforms.
  321. The full Eiffel source code of the compiler itself (in
  322. Eiffel) is included. See QCOM.
  323.  
  324. A ready-to-run package for Windows, including a freeware C
  325. compiler, is available at http://elj.sourceforge.net/
  326.  
  327. Many commercial vendors offer free evaluation versions, with
  328. some limitations. Commercial vendors often also have cheap
  329. entry-level versions for popular platforms like Win32 and
  330. Linux on x86 PCs.
  331.  
  332.  --------------------
  333.  
  334. QARC: Is there an archive of the comp.lang.eiffel newsgroup?
  335.  
  336. Yes, it is on Google groups:
  337.  http://groups.google.com/groups?group=comp.lang.eiffel
  338.  
  339.  --------------------
  340.  
  341. QBOK: What books are available for learning about Eiffel?
  342.  
  343.  
  344. ESSENTIAL READING
  345.  
  346.  Title: Object-Oriented Software Construction, second edition
  347. Author: Bertrand Meyer
  348.   ISBN: ISBN 0-13-629155-4 - Prentice Hall 1997
  349.  Short: This book is the comprehensive reference on all aspects of
  350.         object technology, from design principles to O-O techniques,
  351.         Design by Contract, O-O analysis, concurrency, persistence,
  352.         abstract data types and many more. While Eiffel is only
  353.         presented as the 'notation' used to illustrate the concept,
  354.         it is essential reading for any Eiffelist -- it includes a
  355.         rather complete description of the 'notation'. It comes with
  356.         a CD-ROM containing the complete hyperlinked text,
  357.         supplementary material, and a version of ISE Eiffel.
  358.  
  359.  Title: Eiffel: The Language
  360. Author: Bertrand Meyer
  361.   ISBN: ISBN 0-13-247925-7 -- Prentice Hall 1992
  362.  Short: This book combines an introduction to Eiffel, the language
  363.         reference, and a good deal of philosophy into its 600 pages.
  364.         This is a rigorous and comprehensive book which some readers
  365.         may find heavy going despite Dr. Meyer's clarity of expression.
  366.         It is the definitive language reference, and essential reading
  367.         for all serious Eiffel users. Get the second or later printing
  368.         (same ISBN), which includes many corrections and changes (there
  369.         is not a second edition, and none is currently underway). This
  370.         book is also available in French (ISBN 2-7296-0525-8).
  371.  
  372. OTHER BOOKS
  373.  
  374.  Title: Design by Contract, by Example
  375. Author: Richard Mitchell, James McKim
  376.   ISBN: 0-20-163460-0 -- Addison Wesley 2001
  377.  Short: An example-based guide to Design by Contract. 
  378.   
  379.  Title: Design Patterns and Contracts
  380. Author: JM Jezequel, M Train, C Mingins -- ISBN 0-20-130959-9 -- AW 1999
  381.  Short: This book builds on the work on software design patterns
  382.         as published in the 'Gang of Four' book by Gamma et al. Design
  383.         by Contract is applied to design patterns.
  384.  
  385.  Title: Objects Unencapsulated: Java, Eiffel, and C++?
  386. Author: Ian Joyner -- ISBN 0-13-014269-7 -- PH 1999
  387.  Short: An examination of the core of object-oriented technology
  388.         through a comparison between Java, Eiffel and C++.
  389.  
  390.  Title: Object Oriented Programming in Eiffel, 2nd edition
  391. Author: Pete Thomas and Ray Weedon -- ISBN: 0-201-33131-4 -- AW 1997
  392.  Short: This book is a very comprehensive Eiffel tutorial and textbook,
  393.         with a solid "Abstract Data Type" approach.
  394.  
  395.  Title: Algorithms and Data Structures
  396. Author: Jeffrey Kingston -- ISBN: 0-201-40374-9 -- AW 1997
  397.  Short: A treatment of the central algorithms and data structures of
  398.         computer science, including complete Eiffel implementations.
  399.  
  400.  Title: An Object-Oriented Introduction to Computer Science Using Eiffel
  401. Author: Richard Wiener -- ISBN: 0-13-838725 -- PH 1997
  402.  Short: None
  403.  
  404.  Title: Object Technology for Scientific Computing Object-Oriented
  405.             Numerical Software in Eiffel and C
  406. Author: Paul Dubois -- ISBN: 0-13-267808-X -- PH 1996
  407.  Short: Accompanying CD with the Free Eiffel for UNIX & Linux
  408.         environments.
  409.  
  410.  Title: Object-Oriented Software Engineering with Eiffel
  411. Author: Jean-Marc Jezequel -- ISBN: 0-201-63381-7 -- AW 1996
  412.  Short: A comprehensive guide to Eiffel. In addition to describing
  413.         Eiffel, the book contains descriptions and comparisons of
  414.         compilers and libraries available on the market.
  415.  
  416.  Title: Object Structures: Building OO Software Components with Eiffel
  417. Author: Jacob Gore -- ISBN: 0-201-63480-5 -- AW 1996
  418.  Short: This is the first "data structures" book for Eiffel, bringing
  419.         to the study of that language the first comprehensive
  420.         treatment of one of the most important topics in any
  421.         programming language.
  422.  
  423.  Title: Eiffel Object-Oriented Programming
  424. Author: John Tyrrell -- ISBN: 0-333-64554-5 -- 1995
  425.  Short: This is an inexpensive and very approachable book.
  426.  
  427.  Title: Software Development Using Eiffel: There can be life other than C++
  428. Author: Richard Wiener -- ISBN: 0-13-100686-X -- PH 1995
  429.  Short: This is a useful book with a lot of code examples for those
  430.         with a grounding in another OO language.
  431.  
  432.  Title: Object Success
  433. Author: Bertrand Meyer -- ISBN: 0-13-192833-3 -- PH 1995
  434.  Short: This book is a  manager's guide to object orientation, its
  435.         impact on the corporation and its use for re-engineering the
  436.         software process.
  437.  
  438.  Title: Object Oriented Programming in Eiffel
  439. Author: R. Rist and R. Terwilliger -- ISBN: 0-13-205931-2 -- PH 1995
  440.  Short: This is a textbook with an emphasis on design.
  441.  
  442.  Title: Seamless Object-Oriented Software Architecture: Analysis and
  443.             Design of Reliable Systems
  444. Author: Kim Walden & Jean-Marc Nerson -- ISBN: 0-13-031303-3 -- PH 1994
  445.  Short: This book describes the Business Object Notation (BON) Method
  446.         in detail.
  447.  
  448.  Title: Reusable Software: The Base Object-Oriented Component Libraries
  449. Author: Bertrand Meyer -- ISBN: 0-13-245499-8 -- PH 1994
  450.  Short: This book describes principles of library design and the
  451.         taxonomy of fundamental computing structures. Serves as a
  452.         manual for the EiffelBase libraries.
  453.  
  454.  Title: An Object-Oriented Environment: Principles and Application
  455. Author: Bertrand Meyer -- ISBN: 0-13-245507-2 -- PH 1994
  456.  Short: This book describes the ISE EiffelBench environment as well as
  457.         the "Melting Ice" compilation technology and the EiffelBuild
  458.         GUI application builder.
  459.  
  460.  Title: Object-Oriented Applications
  461. Author: Meyer and Nerson editors -- ISBN: 0-13-013798-7 -- PH 1993
  462.  Short: This book includes an introduction to Eiffel technology
  463.         followed by seven in-depth descriptions of large applications
  464.         written in Eiffel.
  465.  
  466.  Title: Eiffel: An Introduction
  467. Author: Robert Switzer -- ISBN: 0-13-105909-2 -- PH 1993
  468.  Short: This book is a very clear and concise Eiffel primer, with many
  469.         code fragments and two substantial Eiffel applications. Also
  470.         available in French (ISBN 2-225-84-656-1).
  471.  
  472.  Title: Object Oriented Software Construction, first edition
  473. Author: Bertrand Meyer -- ISBN: 0-13-629049-3 -- PH 1988
  474.  Short: An earlier edition of the second edition mentioned above, based
  475.         on a previous version of the language.
  476.         Also available in French, German, Italian, Dutch, etc.
  477.  
  478. Publishers are Addison Wesley (AW) and Prentice Hall (PH).
  479.  
  480.  --------------------
  481.  
  482. QWEB: Where can I find Eiffel on the World-Wide-Web?
  483.  
  484. http://www.cetus-links.org/oo_eiffel.html
  485.   Cetus Links is a directory of resources on object-oriented
  486.   programming, including useful Eiffel pages.
  487.  
  488. http://www.gobosoft.com/
  489.   The home of the Gobo Eiffel project.
  490.  
  491. The main vendors websites are:
  492.  
  493.  Eiffel Software   http://www.eiffel.com/
  494.  Object Tools      http://www.object-tools.com/
  495.  SmartEiffel       http://smarteiffel.loria.fr/
  496.  
  497.  
  498.  --------------------
  499.  
  500. QEDI: Where can I get an Eiffel editor or emacs-mode?
  501.  
  502. Tower Technology developed an Eiffel 3 emacs mode that supports
  503. syntax-directed highlighting, auto-indentation and is easily
  504. customized for font use, color and indentation amounts.
  505.  
  506. The WINEDIT shareware programmer's editor offers colour syntax
  507. highlighting, works with Eiffel/S under MS-Windows, and is available
  508. from all main Windows shareware archives.
  509.  
  510. Alan Philips' free Programmers File Editor also works with Eiffel/S
  511. under MS-Windows, has templates but not syntax highlighting, available
  512. from http://www.lancs.ac.uk/people/cpaap/pfe/
  513.  
  514. The vim editor, an enhanced version of Unix's vi, includes Reimer
  515. Behrend's Eiffel syntax file as part of the standard distribution,
  516. from http://www.vim.org/
  517.  
  518. An Eiffel extension to the Windows programmers editor Codewright
  519. from Premia implements chromacoding of Eiffel code, smart indenting
  520. and some templates; from http://www.nenie.org/eiffel/free/
  521.  
  522. The commercial Windows editor TextPad (http://www.textpad.com/) has
  523. a number of Eiffel syntax highlighting extensions.
  524.  
  525.  --------------------
  526.  
  527. QBON: What is BON?
  528.  
  529. BON ("Business Object Notation") is a method for high-level analysis
  530. and design, offering a seamless reversible transition to an Eiffel
  531. implementation. The method emphasizes Design by Contract and
  532. systematic development. It is described in Walden and Nerson's book
  533. 'Seamless Object-Oriented Software Architecture' which is available 
  534. online at http://www.bon-method.com/ along with other resources 
  535. on the method.
  536.  
  537. Eiffel Software supports BON within EiffelStudio.
  538.  
  539.  --------------------
  540.  
  541. QSTD: Are there standards for the Eiffel language?
  542.  
  543. The definition of the Eiffel language is in the public domain. This
  544. definition was initially controlled by NICE, the Non-profit
  545. International Consortium for Eiffel, a group of Eiffel vendors
  546. and users. Membership is currently free and anyone interested in 
  547. the promotion and standardisation of the language can join.
  548. http://www.eiffel-nice.org/
  549.  
  550. Most of the standardisation work has been taken over by an 
  551. ECMA committee who produced ECMA 367, the new Eiffel standard:
  552. http://www.ecma-international.org/publications/standards/Ecma-367.htm
  553. It supercedes Bertrand Meyer's book, "Eiffel: The Language" (2nd 
  554. Printing). A draft of the next edition of this book incorporating 
  555. the new standard and to be titled "Standard Eiffel", is available
  556. online from Bertrand Meyer's page at ETH: 
  557. http://www.inf.ethz.ch/personal/meyer/
  558.  
  559.  --------------------
  560.  
  561. QPOR: How do I write portable applications?
  562.  
  563. It is possible to achieve reasonable code portability between
  564. supported Eiffel compilers, when care is taken not to use proprietary
  565. features or new extensions or obscure features of the language
  566. whose implementations may vary.
  567.  
  568. Portability between several operating systems supported by a
  569. given compiler is generally quite good.
  570.  
  571. The situation is less straightforward with libraries. The
  572. only official library standard is the ELKS-2001 kernel standard.
  573. The core features and classes are portable if vendor-specific
  574. features are avoided, but the functionality coverage is limited.
  575.  
  576. ELKS-2001 does not include container classes (except ARRAY). Eiffel
  577. Software has released its data structure library, EiffelBase, as open
  578. source, and some other vendors support it with their compiler but it
  579. does not work with others.
  580.  
  581. Eric Bezault's open source Gobo library (http://www.gobosoft.com/) is
  582. probably the most widely used alternative library, and it has been
  583. made portable to all current compilers. It includes an EiffelBase
  584. emulation cluster so that most applications developed using
  585. EiffelBase can be ported to any compiler using Gobo. Beyond
  586. data structures, it includes essential functionality not
  587. covered in ELKS-95 and abstractions of some differences between
  588. Eiffel compilers.
  589.  
  590.  --------------------
  591.  
  592. QTGV: How fast do Eiffel applications run?
  593.  
  594. Eiffel is a statically typed object-oriented language using
  595. automatic memory management.
  596.  
  597. Many Eiffel compilers make use of the static typing and perform
  598. extensive global optimisations producing performance comparable
  599. with other well-optimised statically typed languages like C++.
  600.  
  601. Eiffel's assertions are normally enabled during development,
  602. and inevitably slow down execution. Assertions are not usually
  603. compiled in production binaries and so have no impact on the
  604. performance of optimised code.
  605.  
  606. The cost of garbage collection is an often debated point, and
  607. large applications are often dominated by memory management rather
  608. than computation. In principle a style of programming assuming a GC
  609. could be more efficient than typical manual memory management. In
  610. any case, there is nothing in Eiffel making garbage collection less
  611. efficient than with any other language where it is used.
  612.  
  613.  --------------------
  614.  
  615. QGRP: Are there any Eiffel user groups?
  616.  
  617. Compiler vendors usually run user groups for their user base, often
  618. in the form of a mailing-list or meetings during conferences. Contact
  619. the individual vendors for more information.
  620.  
  621. A number of online discussion groups about Eiffel are hosted at Eiffel
  622. Software's discussion site (http://www.talkitover.com/) and on Yahoo
  623. Groups (http://groups.yahoo.com/). These sites provide both e-mail and
  624. web-based interfaces.
  625.  
  626. Many Eiffel projects are hosted at Sourceforge, the free open source
  627. hosting site. http://www.sourceforge.net/
  628.  
  629. South American users of Eiffel can look at the home page of RIPLEG
  630. (Rio de la Plata Eiffel Group). http://www.ripleg.com.ar/
  631.  
  632. The Colorado Eiffel User's Group meets in Denver and has a mailing
  633. list at http://groups.yahoo.com/group/colorado_eiffel_users/
  634.  
  635. GFUE is the user group for French speakers.
  636. http://gfue.eiffelsolution.com/
  637.  
  638.  --------------------
  639.  
  640. QADR: Where can I get Eiffel products and services?
  641.  
  642. These vendors, resellers and suppliers of Eiffel training and
  643. consultancy are listed in alphabetical order:
  644.  
  645. - Cap Gemini France, Division ITMI, http://www.capgemini.fr/
  646. - Class Technology Pty. Ltd., http://www.class.com.au/
  647. - Eiffel Ireland, http://www.eiffel.ie/Eiffel/
  648. - Enea Data, http://www.enea.se/
  649. - Everything Eiffel, http://www.eiffel.demon.co.uk/
  650. - Information and Math Science Lab Inc., http://www.imslab.co.jp/
  651. - Eiffel Software, Inc. http://www.eiffel.com/
  652. - Object Tools GmbH, http://www.object-tools.com/
  653.  
  654.  --------------------
  655.  
  656. QCNF: Are there any conferences for Eiffel users?
  657.  
  658. TOOLS is an international conference devoted to the applications of
  659. OO technology. It is organised by Eiffel Software and a popular conference
  660. with Eiffelists. EiffelStudio user group meetings occur concurrently.
  661. http://www.tools-conferences.com/
  662.  
  663. The ACM SIGPLAN Conference On Object-Oriented Programming Systems,
  664. Languages and Applications (OOPSLA) is probably the largest technical
  665. conference about OO Technology.
  666. http://www.acm.org/sigplan/oopsla/
  667.  
  668. ECOOP is the annual European Conference for Object-Oriented
  669. Programming. http://www.ecoop.org/
  670.  
  671.  --------------------
  672.  
  673. QECC: Why do many Eiffel implementations compile to C?
  674.  
  675. By using C as a target language, an Eiffel implementor can:
  676.  
  677.  - bring Eiffel to the marketplace faster and at lower cost
  678.  - port their implementation more easily to other platforms
  679.  - take advantage of optimisation provided by the C compiler
  680.  
  681. Much of the technology that makes Eiffel relatively simple to use also
  682. makes it more difficult to implement than say a native code Pascal
  683. compiler.
  684.  
  685. Compiling Eiffel to C seems to work well under Unix. C is sometimes
  686. thought of as the native code of Unix.
  687.  
  688. Still, there are quite a few compilers that can compile to other
  689. targets, such as the Java or .NET virtual machines, or x86
  690. assembly language.
  691.  
  692.  --------------------
  693.  
  694. QJVM: Where can I get an Eiffel to Java compiler?
  695.  
  696. An Eiffel compiler that targets the Java Virtual Machine (JVM) is
  697. a common request. While it is tempting to think that this could be 
  698. done so that there total interoperability between Java and Eiffel
  699. code, things are not as simple as they look at first sight.
  700. There are fundamental differences between the Java and Eiffel object
  701. models (dynamic vs. static object systems, single vs. multiple
  702. inheritance, design by contract vs. wishful thinking, are among the
  703. problems).
  704.  
  705. While it is of course possible to provide a compiler from Eiffel to
  706. the JVM (which is a Turing machine), it comes necessarily at a cost,
  707. be it performance or interoperability or both. It is unlikely in the
  708. foreseeable future to have an Eiffel to JVM compiler where it is
  709. possible to mix and match freely classes written in Java and Eiffel
  710. classes without having to worry about which language they are
  711. written in.
  712.  
  713. Nevertheless, most compiler vendors are moving towards providing
  714. some support for the JVM, with differing limitations depending on
  715. the vendor and implementation strategy.
  716.  
  717. SmartEiffel is the first compiler available to produce some
  718. usable result on the JVM. Eiffel Software and Object Tools
  719. have announced ongoing efforts to support Java.
  720.  
  721.  --------------------
  722.  
  723. QNET: Where can I get an Eiffel to .NET compiler?
  724.  
  725. Eiffel Software's current compiler includes the ability to
  726. generate code for Microsoft's Common Language Infrastructure,
  727. the .NET runtime environment. Eiffel Software is also
  728. involved in the ECMA (European Computer Manufacturers
  729. Association) standardisation effort for the CLI. Both
  730. the standalone environment and the add-on for Visual
  731. Studio (ENViSioN) can be used to produce .NET code.
  732.  
  733. While the early version of this .NET target only supported a
  734. ad-hoc subset of Eiffel, the current version supports the
  735. full Eiffel language. Features of Eiffel not directly supported
  736. by the .NET object model, are implemented on top of the core
  737. features.
  738.  
  739.  --------------------
  740.  
  741. LFEA: What features does Eiffel have?
  742.  
  743. Eiffel is a pure, statically typed, object-oriented language. Its
  744. modularity is based on classes. Its most notable feature is probably
  745. design by contract. It brings design and programming closer together.
  746. It encourages maintainability and the re-use of software components.
  747.  
  748. Eiffel offers classes, multiple inheritance, polymorphism, static
  749. typing and dynamic binding, genericity (constrained and
  750. unconstrained), a disciplined exception mechanism, systematic use of
  751. assertions to promote programming by contract.
  752.  
  753. Eiffel has an elegant design and programming style, and is easy to
  754. learn.
  755.  
  756. An overview is available at
  757. http://www.eiffel.com/doc/manuals/language/intro/
  758.  
  759.  --------------------
  760.  
  761. LCHN: What changes have been made to the Eiffel language definition?
  762.  
  763. Eiffel is still a relatively new language, and there have been a
  764. number of changes to its definition.
  765.  
  766. There were significant changes between the publication of
  767. "Object-Oriented Software Construction", first edition in 1988,
  768. and the release of Eiffel 2.3.
  769.  
  770. More significant changes came with the introduction of Eiffel 3, the
  771. current and only version of the language in use today. These changes
  772. are summarised in Eiffel: The Language.
  773.  
  774. There were some less significant changes between the first
  775. and second printings of "Eiffel: The Language": new
  776. non-expanded basic types (INTEGER_REF, REAL_REF, etc), POINTER
  777. type to enable external references to be passed around, call to
  778. external routines no longer implicitly pass the current
  779. object as the first parameter.
  780.  
  781. Since then the following change has been adopted and widely
  782. implemented:
  783.  
  784.    - The Precursor construct allows the ancestor's version of
  785.      a redefined feature to be conveniently called (see LPAR).
  786.  
  787.    - A keyword-based notation (create/creation) for object creation 
  788.      was introduced as an alternative to the "!!" notation.
  789.      
  790. Bertrand Meyer is currently working on Eiffel: The Language,
  791. third edition, which will describe a significantly updated version
  792. of the language, known as 'Eiffel 5'. Some of the constructs being
  793. introduced, like Agents (routines as a first class construct),
  794. have already found their way into Eiffel Software's implementation.
  795.  
  796. The draft for this next edition is reachable from Bertrand Meyer's 
  797. home page at http://www.inf.ethz.ch/~meyer/publications/
  798.  
  799.  --------------------
  800.  
  801. LLIB: What libraries come with Eiffel?
  802.  
  803. All vendors aim to support the Eiffel Library Standard kernel classes.
  804.  
  805. In addition, extensive library classes are supplied with the compilers
  806. including data structures, graphics, lexical analysis and parsing, IO,
  807. persistence, formatting, GUI and more.
  808.  
  809. Many libraries are provided by third parties, mostly as open source
  810. code. There are too many to list here. A good starting point is at
  811. http://www.cetus-links.org/oo_eiffel_libraries.html
  812.  
  813.  --------------------
  814.  
  815. LDBC: What's the big deal about preconditions and postconditions?
  816.  
  817. The big deal is that it supports programming by contract. For example,
  818. preconditions (require clauses) are simple boolean statements that are
  819. used to check that the input arguments are valid and that the object
  820. is in a reasonable state to do the requested operation. If not, an
  821. exception is generated. Similarly, postconditions (ensure clauses)
  822. make sure that a method has successfully performed its duties, thus
  823. "fulfilling its contract" with the caller. Invariants are boolean
  824. expressions that are checked every time an object method returns back
  825. to a separate object.
  826.  
  827. You can use these ideas in any OO programming language, but usually
  828. must supply your own assertion mechanisms or rely on programmer
  829. discipline. In Eiffel, the ideas are integrated into the whole fabric
  830. of the environment. We find them used by:
  831.  
  832.  - the exception handling mechanism.
  833.    (Tracebacks almost always identify the correct culprit code since
  834.    preconditions almost always denote an error in the calling method,
  835.    while postconditions denote an error in the called method.)
  836.  
  837.  - the automatic compilation system.
  838.    (Assertions can be disabled entirely or selectively by type on a
  839.    per class basis.)
  840.  
  841.  - the Eiffel compiler.
  842.    (Invariants, preconditions and postconditions are all inherited in
  843.    a manner that makes logical sense.)
  844.    (Assertion expressions are not allowed to produce side effects so
  845.    they can be omitted without effect.)
  846.  
  847.  - the automatic documentation tools.
  848.    (Preconditions and postconditions are important statements about
  849.    what a method does, often effectively describing the "contract"
  850.    between the caller and callee. Invariants can yield information
  851.    about legal states an object can have.)
  852.  
  853. In the future we expect to see formal methods technology work its way
  854. into the assertion capability. This will allow progressively more
  855. powerful constraints to be put into place. In addition, Meyer has
  856. argued in his concurrency model (see LTSK) that assertions play
  857. a central role in concurrent and distributed object-oriented
  858. programming.
  859.  
  860.  --------------------
  861.  
  862. LOLD: What does the 'old' keyword mean?
  863.  
  864. "The value of an Old expression old e is [...] the result 
  865. that would have been produced by evaluation e just before 
  866. the call's execution began." (ETL2, p.125). This is 
  867. useful in postconditions.
  868.  
  869. When using the keyword with a reference, it is clear 
  870. from the definition that the value of "old a" will be 
  871. the object to which 'a' referred at the beginning of 
  872. the routine, and not the old value of the actual 
  873. object. Obtaining a copy of 'a', if that is the 
  874. required semantics, has to be done explicitly:
  875.  
  876.   ... old (clone (a)) ...
  877.   
  878. This makes senses because copy and identity are issues 
  879. with multiple solutions -- a shallow copy as done by 
  880. 'clone' by default may not be enough for instance -- and 
  881. a compiler cannot be reasonably expected to guess correctly 
  882. which interpretation is appropriate for a given usage.
  883.  
  884.  --------------------
  885.  
  886. LCQS: What is command/query separation?
  887.  
  888. It is a convention in Eiffel that functions (routines
  889. that return something) must not have side effects. This
  890. means all routines changing the state of an object should
  891. be procedures, not functions. If they return a result,
  892. a helper attribute can be used.
  893.  
  894. For instance, a typical Eiffel class representing a
  895. facility to read a file will offer a routine to read
  896. a line, and make the result available separately, so 
  897. a client will do:
  898.  
  899.   a_file.read_line -- read_line is a procedure
  900.   do_something_with (a_file.last_string)
  901.  
  902. This is essential for design by contract, because assertions
  903. are boolean expressions that must not change the state of the
  904. objects, otherwise the program will behave differently when
  905. assertions are checked.
  906.  
  907. Internal side effects, that change the concrete but not
  908. the abstract state of the object and are not visible from
  909. outside are acceptable.
  910.  
  911.  --------------------
  912.  
  913. LCON: Please explain and discuss covariance vs. contravariance.
  914.  
  915. Consider the following situation: we have two classes PARENT and
  916. CHILD. CHILD inherits from PARENT, and redefines PARENT's feature
  917. 'foo'.
  918.  
  919.    class PARENT
  920.       feature
  921.          foo (arg: A) is ...
  922.    end
  923.  
  924.    class CHILD
  925.       inherit
  926.          PARENT redefine foo end
  927.       feature
  928.          foo (arg: B) is ...
  929.    end
  930.  
  931. The question is: what restrictions are placed on the type of argument
  932. to 'foo', that is 'A' and 'B'? (If they are the same, there is no
  933. problem.)
  934.  
  935. Here are two possibilities:
  936.  
  937.    (1)  B must be a child of A (the covariant rule - so named because
  938.         in the child class the types of arguments in redefined
  939.         routines are children of types in the parent's routine, so the
  940.         inheritance "varies" for both in the same direction)
  941.  
  942.    (2)  B must be a parent of A (the contravariant rule)
  943.  
  944. Eiffel uses the covariant rule.
  945.  
  946. At first, the contravariant rule seems theoretically appealing. Recall
  947. that polymorphism means that an attribute can hold not only objects of
  948. its declared type, but also of any descendant (child) type. Dynamic
  949. binding means that a feature call on an attribute will trigger the
  950. corresponding feature call for the *actual* type of the object, which
  951. may be a descendant of the declared type of the attribute. With
  952. contravariance, we can assign an object of descendant type to an
  953. attribute, and all feature calls will still work because the
  954. descendant can cope with feature arguments at least as general as
  955. those of the ancestor. In fact, the descendant object is in every way
  956. also a fully-valid instance of the ancestor object: we are using
  957. inheritance to implement subtyping.
  958.  
  959. However, in programming real-world applications we frequently need to
  960. specialize related classes jointly.
  961.  
  962. Here is an example, where PLOT_3D inherits from PLOT, and
  963. DATA_SAMPLE_3D inherits from DATA_SAMPLE.
  964.  
  965.    class PLOT
  966.       feature
  967.          add(arg: DATA_SAMPLE) is ...
  968.  
  969.    class PLOT_3D
  970.       inherit
  971.          PLOT redefine add end
  972.       feature
  973.          add(arg: DATA_SAMPLE_3D) is ...
  974.  
  975. This requires the covariant rule, and works well in Eiffel.
  976.  
  977. It would fail if we were to put a PLOT_3D object into a PLOT attribute
  978. and try to add a DATA_SAMPLE to it. It fails because we have used
  979. inheritance to implement code re-use rather than subtyping, but have
  980. called a feature of the ancestor class on an object of the descendant
  981. class as if the descendant object were a true subtype. It is the
  982. compiler's job to detect and reject this error, to avoid the
  983. possibility of a run-time type error.
  984.  
  985. Here's another example where a real-world situation suggests a
  986. covariant solution. Herbivores eat plants. Cows are herbivores. Grass
  987. is a plant. Cows eat grass but not other plants.
  988.  
  989.    class HERBIVORE                               class PLANT
  990.    feature
  991.       eat(food: PLANT) is ...
  992.       diet: LIST[PLANT]
  993.  
  994.    class COW                                     class GRASS
  995.    inherit                                       inherit
  996.       HERBIVORE                                     PLANT
  997.          redefine eat
  998.       end
  999.    feature eat(food: GRASS) is ...
  1000.  
  1001. This does what we want. The compiler must stop us from putting a COW
  1002. object into a HERBIVORE attribute and trying to feed it a PLANT, but
  1003. we shouldn't be trying to do this anyway.
  1004.  
  1005. Also consider the container 'diet'. We are not forced to redefine this
  1006. feature in descendant classes, because with covariant redefinition of
  1007. the argument to 'eat', the feature 'diet' can always contain any
  1008. object that can be eaten (e.g. grass for a cow). (With contravariant
  1009. redefinition of the argument to 'eat', it would be necessary to
  1010. re-open the parent class to make the type of the container 'diet' more
  1011. general.)
  1012.  
  1013. To summarise: Real-world problems often lend themselves to covariant
  1014. solutions. Eiffel handles these well. Incorrect programs in the
  1015. presence of covariant argument redefinition can cause run-time type
  1016. errors unless the compiler catches these.
  1017.  
  1018.  --------------------
  1019.  
  1020. LCAT: Is it true that there are "holes" in the Eiffel type system?
  1021.  
  1022. Eiffel was designed to make it possible to catch all type errors at
  1023. compile time, so that no type error can occur at run time.
  1024.  
  1025. However, there are some complex cases where the type checking
  1026. is difficult. The solution in Eiffel the Language, system level
  1027. validity checking, requires a global analysis of the whole system,
  1028. which has proven too complex and too impractical to implement.
  1029.  
  1030. Object Oriented Software Construction, second edition, offers a new
  1031. simpler way to check for those errors that may, if refined, provide
  1032. effective type checking but it has been questioned whether it is
  1033. too drastic so that it will make many common patterns invalid.
  1034.  
  1035. The main system-level type errors are:
  1036.  - restriction of exports in a descendant class.
  1037.  - covariant redefinition of routines parameters as in question LCON.
  1038.  - covariant signatures in conforming types of a generic class
  1039.    (like 'put' in LIST[ANY] and LIST[STRING]).
  1040.  - creation of redefined anchor types.
  1041.  - more obscure cases like selection of a feature that returns a
  1042.    precursor type in a multiple inheritance hierarchy, or
  1043.    indirect assignment of references to an expanded ancestor.
  1044.  
  1045. No compiler currently available fully implements these checks and
  1046. behaviour in those cases ranges from run-time type errors to system
  1047. crashes.
  1048.  
  1049. A comprehensive description of these issues and proposed solutions 
  1050. is described in this paper:
  1051.  http://www.inf.ethz.ch/~meyer/ongoing/covariance/recast.pdf
  1052.  
  1053.  --------------------
  1054.  
  1055. LTSK: Is there support for concurrency in Eiffel?
  1056.  
  1057. Eiffel supports concurrency in the latest specification of the
  1058. language. The SCOOP (Simple Concurrent Object-Oriented Programming)
  1059. model is described in chapter 30 of the book in "Object Oriented
  1060. Software Construction 2nd edition" by Bertrand Meyer. Papers are
  1061. also available at
  1062.  http://www.eiffel.com/doc/manuals/technology/concurrency/
  1063.  
  1064. Several researchers and vendors are working towards actual
  1065. implementations of SCOOP.
  1066.  
  1067. In the meantime, most compilers also support less safe forms 
  1068. of concurrency, like multithreading, independently of SCOOP.
  1069.  
  1070.  --------------------
  1071.  
  1072. LOVL: Why doesn't Eiffel allow function overloading?
  1073.  
  1074. In Eiffel, no two features of a class may have the same identifier,
  1075. regardless of their respective signatures.  This prevents the use of
  1076. function overloading, a common programming technique in languages
  1077. like C++.
  1078.  
  1079. Eiffel is designed to be minimal: it includes exactly the features
  1080. that its designer considered necessary, and nothing else.
  1081.  
  1082. Because Eiffel already supports (single) polymorphism through its
  1083. inheritance system, the only positive thing that function overloading
  1084. buys you is reducing the number of feature names, at the expense of
  1085. reducing the ability of the compiler to detect (type) errors.
  1086.  
  1087. Readability is also enhanced when overloading is not possible. With
  1088. overloading you would need to consider the type of the arguments as
  1089. well as the type of the target before you can work out which feature
  1090. is called. With multiple inheritance and dynamic binding this is
  1091. awkward for a compiler and error-prone for a human.
  1092.  
  1093. Having said that, the lack of overloading may force us to write some
  1094. common mathematical operations (e.g. matrix math) in an awkward
  1095. way, and some basic arithmetic expressions are treated specially
  1096. (the "arithmetic balancing rule", ETL p385).
  1097.  
  1098.  --------------------
  1099.  
  1100. LINC: Why is there no increment operator?
  1101.  
  1102. In C-like languages, there is an operator used to increment 
  1103. integer types (++) while in Eiffel one has to write:
  1104.  
  1105.  an_int := an_int + 1
  1106.  
  1107. An operator like ++ would be a procedure, and therefore 
  1108. change the state of the target. If Eiffel's INTEGER had 
  1109. this operator, it would become a mutable value, and 
  1110. lose the benefits it gets from being, along with the other 
  1111. numeric types, immutable. Mutable numeric types would 
  1112. allow clients to circumvent safety features of the type 
  1113. system (function parameter and attribute assignment 
  1114. restrictions for instance).
  1115.  
  1116.  --------------------
  1117.  
  1118. LAGE: What are Eiffel agents?
  1119.  
  1120. In the early years of Eiffel, the language had no routine types
  1121. because having routines as distinct entities outside objects
  1122. was seen as incompatible with the OO method.
  1123.  
  1124. Nevertheless, it has now been accepted that routines as first
  1125. class objects are essential and the 'agents' facility has been
  1126. introduced. It has been implemented at least in part in Eiffel
  1127. Software's compiler and SmartEiffel. Other active vendors are
  1128. likely to follow.
  1129.  
  1130. While this feature is new and the standard is being finalised,
  1131. the core concepts, routine types and tuples for representing
  1132. the parameters and return type of a routine, are now well
  1133. understood.
  1134.  
  1135. An ordinary agent is created within the current object,
  1136. which provides a context and makes the facility as expressive as
  1137. higher order functions (closures) in functional programming
  1138. languages.
  1139.  
  1140.  --------------------
  1141.  
  1142. LATR: Why are there no class attributes in Eiffel?
  1143.  
  1144. In Eiffel, the "once" function provides greater functionality in a
  1145. more disciplined way. The body of a "once" function is executed once
  1146. only per system (not per instance of the class), when it is first
  1147. called. Thereafter, the "once" function returns the same Result
  1148. without re-executing its body.
  1149.  
  1150. Such functions can be used to implement a shared attribute of 
  1151. reference type, which is initialized on its first use.
  1152.  
  1153. A "once" function can be included in a mixin class. The shared
  1154. attribute returned by that once function is then available to all
  1155. instances of classes which inherit from the mixin class.
  1156.  
  1157.  --------------------
  1158.  
  1159. LPAR: How can I call the parent-class version of a redefined routine?
  1160.  
  1161. This was a problem that required the use of multiple inheritance or
  1162. synonyms with earlier versions of Eiffel, before the Precursor
  1163. construct was introduced.
  1164.  
  1165. This construct has now been implemented by all supported compilers,
  1166. so calling a parent version of a redefined routine just requires
  1167. using the Precursor keyword in the body of the redefinition.
  1168.  
  1169. The construct is described in an a paper at
  1170. http://www.eiffel.com/doc/manuals/language/precursor/
  1171.  
  1172.  --------------------
  1173.  
  1174. LEVC: Where can I find a comparison between Eiffel and other languages?
  1175.  
  1176. Ian Joyner's "C++ critique" includes a comparison between C++, Eiffel
  1177. and other languages. It has been published as a book, Objects 
  1178. Unencapsulated (see QBOK).  It is also available online:
  1179. http://burks.brighton.ac.uk/burks/pcinfo/progdocs/cppcrit/
  1180.  
  1181.  
  1182. In Richard Wiener's book "Software Development Using Eiffel: There can
  1183. be life after C++" (see QBOK).
  1184.  
  1185. There is another comparison of Eiffel, C++, Java, and Smalltalk at
  1186. http://www.eiffel.com/doc/manuals/technology/oo_comparison/
  1187.  
  1188.  --------------------
  1189.  
  1190. LDES: Are there any destructors in Eiffel?
  1191.  
  1192. Eiffel objects are garbage-collected, so that there is no need for the
  1193. developer to explicitly "destroy" or "free" them.
  1194.  
  1195. Nevertheless the need may arise to ensure that certain operations
  1196. will automatically take place whenever the garbage collector reclaims
  1197. an object. For example if an object describing a file becomes
  1198. unreachable and hence is eventually garbage-collected, you may want
  1199. to ensure that the operating system file will be closed at that
  1200. time. Most implementations of Eiffel provide a mechanism for that
  1201. purpose: procedure 'dispose' from the Kernel Library class MEMORY.
  1202.  
  1203. Whenever the garbage collector collects an object, it calls 'dispose'
  1204. on that object. The procedure does nothing by default. Any class may
  1205. inherit from MEMORY and redefine 'dispose' to perform appropriate
  1206. actions, such as closing a file. Such actions are sometimes called
  1207. "finalization".
  1208.  
  1209. Because there is no guarantee as to the order in which the garbage
  1210. collector will reclaim objects that have become unreachable, safe
  1211. redefinitions of 'dispose' should only act on external resources and
  1212. not touch Eiffel object structures which may have already been freed.
  1213.  
  1214.  --------------------
  1215.  
  1216. LDIS: How do I implement multiple inheritance efficiently?
  1217.  
  1218. People with a background in C++ or single-inheritance languages
  1219. often think that multiple inheritance carries a penalty because
  1220. it cannot be implemented using the classic dispatch table scheme
  1221. (where every polymorphic feature has a fixed position in a pointer
  1222. table that descendants can customise without breaking any code
  1223. using the fixed position of an ancestor's polymorphic feature.)
  1224.  
  1225. There are other ways to implement inheritance which allows Eiffel
  1226. not to suffer performance problems because of multiple inheritance.
  1227. Eiffel compilers generally use one of two methods.
  1228.  
  1229. In both cases, we need to assume that every type in the system is
  1230. assigned an integer identifier -- the type ID.
  1231.  
  1232. The first implementation is the 'sparse matrix' model. Every
  1233. polymorphic feature has an associated pointer table with an entry
  1234. for each type, indexed by type ID. This allows all polymorphic
  1235. calls to be executed at the (same) cost of a single pointer
  1236. dereferencing.
  1237.  
  1238. The immediate drawback of this, is that it generates a rather big
  1239. data table (a matrix of all polymorphic routines by all types in
  1240. a system). Fortunately, there are sparse matrix algorithms allowing
  1241. to compress these tables efficiently by carefully selecting the IDs
  1242. (an evident optimisation is to try to group all descendant next
  1243. to their parent so that only a short section of the type ID space
  1244. need be covered).
  1245.  
  1246. The other method is different and uses the equivalent of an inspect 
  1247. statement on the type ID, calling the appropriate static function for 
  1248. each concrete dynamic type. In this case, it is obvious that the
  1249. compiler needs a global knowledge of the system: for each polymorphic
  1250. routine call, it needs to know all concrete subtypes really used in
  1251. the system, and all redefinitions of the routines.
  1252.  
  1253. At first sight, it could be thought that the inspect statement could
  1254. slow down the system. Actual compilers using this solution have proved
  1255. that they can be as efficient as (or more than) those implemented
  1256. using the first method.
  1257.  
  1258. It should now be clear that, for both methods, it is necessary
  1259. for the compiler to have at compile time -- or at the very least at
  1260. optimisation time -- a view of the complete system. This could appear
  1261. like a serious restriction but it is not much of a concern because
  1262. optimising Eiffel compilers must have this view in the first place 
  1263. in order to be able to differentiate between static and polymorphic 
  1264. routines -- all routines being potentially polymorphic in Eiffel.
  1265.  
  1266.  --------------------
  1267.  
  1268. LISA: How does the `Iterating several actions' example in ETL work?
  1269.  
  1270. The example code page 176 of Eiffel: The Language, 2nd printing does
  1271. not work with any widely available compiler. It has confused and
  1272. puzzled many newcomers to the language and what it is supposed to
  1273. do is not clearly defined in the book.
  1274.  
  1275. What the example should do is as follows. When a feature is replicated
  1276. under multiple inheritance (renamed so that the feature is now known
  1277. under two names) and in the same inheritance clause a routine or
  1278. attribute its source text references is also replicated, the routine
  1279. body of the first feature should be adapted to call the corresponding
  1280. replicated features on each path of the inheritance. The mechanism
  1281. is not intended to scale to more complex cases where the replication
  1282. does not occur in a single inheritance clause.
  1283.  
  1284. This feature is now considered obsolete because agents (see LAGE) are
  1285. now available and provide a more convenient solution for this pattern.
  1286.  
  1287.  --------------------
  1288.  
  1289. LORB: Is COM/CORBA supported?
  1290.  
  1291. COM or CORBA support is not built into the language. Most
  1292. commercial vendors supporting Windows have a COM package
  1293. that is tied to their compiler.
  1294.  
  1295. There is an open source CORBA object request broker,
  1296. MICO/E, at http://www.math.uni-goettingen.de/micoe/
  1297.  
  1298. 2ab, Inc., at http://www.2ab.com/, has an Eiffel
  1299. binding for their CORBA package which works with ISE
  1300. Eiffel.
  1301.  
  1302.