Path: news1.ucsd.edu!ihnp4.ucsd.edu!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!serv.hinet.net!nctuccca.edu.tw!howland.erols.net!newsfeed.internetmci.com!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
From: Conrad Taylor <conradt@comm.mot.com>
Newsgroups: comp.lang.eiffel,comp.answers,news.answers
Subject: comp.lang.eiffel Frequently Asked Questions (FAQ)
Supersedes: <eiffel-faq_839536521@rtfm.mit.edu>
Followup-To: comp.lang.eiffel
Date: 8 Sep 1996 18:57:03 GMT
Organization: none
Lines: 1385
Approved: news-answers-request@mit.edu
Expires: 22 Oct 1996 18:53:35 GMT
Message-ID: <eiffel-faq_842208815@rtfm.mit.edu>
Reply-To: conradt@comm.mot.com
NNTP-Posting-Host: bloom-picayune.mit.edu
X-Last-Updated: 1996/09/03
Originator: faqserv@bloom-picayune.MIT.EDU
Xref: news1.ucsd.edu comp.lang.eiffel:10510 comp.answers:16226 news.answers:64940
Archive-name: eiffel-faq
Posting-Frequency: approximately monthly
Last-modified: 3 Sep 1996
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, additions and comments to Conrad Taylor
(conradt@sc.comm.mot.com).
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 Conrad Taylor. Distribution over the Internet or
by electronic mail is unrestricted. Other use requires my permission.
You can receive the latest copy by anonymous file transfer from:
ftp://ftp.cm.cf.ac.uk/pub/eiffel/eiffel-faq
ftp://rtfm.mit.edu/pub/usenet/news.answers/eiffel-faq
or by sending an email message to archive-server@cm.cf.ac.uk with this
message body:
send comp.lang.eiffel-faq eiffel-faq
----------
CONTENTS
Changes since the last posting:
What's New:
N01) EiffelWorld Online
Frequently Asked Questions:
Q01) What is Eiffel?
Q02) Where did Eiffel come from?
Q03) What Eiffel products are available?
Q04) Is Eiffel available for free or as shareware?
Q05) Is there an archive of the comp.lang.eiffel newsgroup?
Q06) What is Sather? How does it compare to Eiffel?
Q07) What books are available for learning about Eiffel?
Q08) Are any magazines or newsletters available concerning Eiffel?
Q09) Where can I find Eiffel on the World-Wide-Web?
Q10) Where can I get an Eiffel editor or emacs-mode?
Q11) What is BON?
Q12) How large are typical Eiffel executables?
Q13) Are there standards for the Eiffel language?
Q14) How fast do Eiffel applications run?
Q15) Are there any Eiffel user groups?
Q16) Where can I get Eiffel products and services?
Q17) Are there any conferences for Eiffel users?
Q18) Why do most Eiffel implementations compile to C?
Language Issues:
L01) What features does Eiffel have?
L02) What changes have been made to the Eiffel language definition?
L03) What libraries come with Eiffel?
L04) What's the big deal about preconditions and postconditions?
L05) Please explain and discuss covariance vs. contravariance.
L06) Is it true that there are "holes" in the Eiffel type system?
L07) Is there support for concurrency in Eiffel?
L08) Why doesn't Eiffel allow function overloading?
L09) Why are there no procedural types in Eiffel?
L10) Why are there no class attributes in Eiffel?
L11) How can I call the parent-class version of a redefined
routine?
L12) Where can I find a comparison between Eiffel and C++?
L13) Are there any destructors in Eiffel?
N01) EiffelWorld Online
We are pleased to announce that EiffelWorld is now
available on-line! This is your first quarterly reminder
to visit the EiffelWorld Online magazine at
http://www.eiffel.com/doc/eiffelworld/5.2
----------
Q01) What is Eiffel?
Eiffel is an advanced object-oriented programming language 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.
----------
Q02) Where did Eiffel come from?
Eiffel was created by Bertrand Meyer and developed by his company,
Interactive Software Engineering (ISE) 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.
----------
Q03) What Eiffel products are available?
Commercial Eiffel compilers, libraries and tools are available from
the following vendors and their resellers:
Interactive Software Engineering Inc (ISE Eiffel)
Tower Technology Corporation (TowerEiffel)
SIG Computer GmbH (Eiffel/S)
Jan Willamowius (Eiffel adaption of SNiFF+ Programming Environment)
The following platforms are supported by one or more of the above
vendors:
PC: DOS, OS/2, Windows 3.1, Windows 95, Windows NT, PC Unix
(Interactive, SCO, and ESIX), Nextstep, Linux
OTHER HARDWARE: Sparc (SunOS & Solaris), NeXTStep, HP9000, DEC 5xxx,
Sony News, DG Aviion, DEC Alpha OSF-1, DEC OpenVMS, RS6000,
Pyramid, QNX, Silicon Graphics, Macintosh (Motorola & PowerPC)
Special offers are available on many of these products for personal or
educational use.
Further information about these products is available from the vendors
by email and on the world-wide-web.
See Q16 for contact details and websites.
----------
Q04) Is Eiffel available for free or as shareware?
All of Eiffel - All graphical - All for free!
FREE EIFFEL FOR WINDOWS is a free version of ISE's acclaimed Melting Ice
Technology compiler and environment for Eiffel. No strings attached -- it's
FREE!
FREE EIFFEL FOR WINDOWS is now fully graphical, showing the power of
the EiffelBench set of advanced development tools for fast
compilation, documentation, browsing, debugging and much more!
The earlier text-based environment is still available, but we think
you'll want to try the graphical environment right away!
Technical support for FREE EIFFEL FOR WINDOWS is available. Details are
included in the delivery, or contact us.
Also of interest
Upgrade to Personal or Professional Eiffel for Windows for an unbeatable
price and get printed documentation, more tools, more libraries, support and
more.
Also note our highly affordable ISE Eiffel for Linux , supporting the entire
set of ISE Eiffel mechanisms for the fastest growing version of Unix. And of
course ISE Eiffel is available for the major platforms in the industry, from
Unix to VMS with more to come.
Getting familiar with the environment
On-line documentation is included in the delivery. But please do us a favor:
if you are new to ISE Eiffel, please take a few minutes (now or later, but
before you start using the environment) to consult the on-line introduction
to EiffelBench. The powerful interaction techniques of ISE Eiffel are
innovative and have been known to startle newcomers. We are sure you will
love them, but first you must read about the essential ideas.
Downloading FREE EIFFEL FOR WINDOWS
Note: if you want the graphical version (who doesn't?) do NOT download it
from SimTel or any of the other sites. At the moment only ISE's site has
FREE GRAPHICAL EIFFEL FOR WINDOWS.
Be sure to choose the version for the appropriate variant of Windows, as
listed below: Windows 95, Windows NT or Windows 3.1. The Windows 3.1 version
will NOT work under 95 or NT.
To download the FREE GRAPHICAL EIFFEL FOR WINDOWS, go to the ISE Web Site:
From the WWW: http://www.eiffel.com
Directly from FTP: ftp.eiffel.com
SIG Computer's "Eiffel/S 1.3s" is a shareware version of their Eiffel
compiler for DOS and Unix and is available by FTP from SimTel mirror
sites in SimTel/msdos/eiffel, or from the UWCC archive
at
ftp//ftp.cm.cf.ac.uk/pub/Eiffel/SIG/Eiffel-S-1.3/
The EON Eiffel compiler is shareware under MS-DOS and Linux, and a
beta-test version is available from
ftp://ftp.demon.co.uk/pub/eiffel/eon-eiffel/
SmallEiffel is a free Eiffel compiler distributed under the terms of
the GNU General Public License as published by the Free Software
Foundation. You can download SmallEiffel at
ftp://ftp.loria.fr/pub/loria/genielog/SmallEiffel
The following Eiffel archive sites allow anonymous file transfer:
ftp://ftp.tu-clausthal.de/pub/atari/languages/eiffel/vici_102.lzh
The Atari ST interpreter referred to above.
ftp://ftp.cm.cf.ac.uk/pub/eiffel
University of Wales. Contains the latest version of this FAQ, plus
the front-end parser (ep) and various public domain classes. To
contribute, contact Ted Lawson (ted@cm.cf.ac.uk).
ftp://ftp.fu-berlin.de/pub/unix/languages/heron
This is an Eiffel front-end parser (HERON) in the public domain,
created by Burghardt Groeber and Olaf Langmack of the Freie
Universitaet in Berlin.
ftp://ftp.informatik.uni-stuttgart.de/pub/eiffel
Falkultaet Informatik der Universitaet Stuttgart, Germany. Contains
a compiler generator, several encapsulations, a pretty-printer for
Eiffel/S, and some utility classes. To contribute, contact Joerg
Schulz (schulz@adam.informatik.uni-stuttgart.de).
ftp://utarlg.uta.edu/CSE/EIFFEL
UT-Arlington, USA. Contains some code from Eiffel Outlook back
issues.
SIG Computer produces a CD-ROM containing most of the available
freeware, shareware and public domain Eiffel material.
----------
Q05) Is there an archive of the comp.lang.eiffel newsgroup?
Yes, at the following FTP sites:
ftp://wuarchive.wustl.edu/usenet/comp.lang.eiffel/
and on the WWW at http://www.cm.cf.ac.uk/CLE/
----------
Q06) What is Sather? How does it compare to Eiffel?
Sather is an OO language, originally patterned after Eiffel but now
very different, created at ICSI of Berkeley, CA.
Sather does not support Design by Contract, but has some other
interesting features. See the usenet newsgroup comp.lang.sather.
----------
Q07) What books are available for learning about Eiffel?
The classic text for learning about Eiffel (and OO programming in
general) is Dr. Meyer's "Object Oriented Software Construction".
Although the language has evolved significantly since the book was
published, the presentation of the basic problems and solutions which
motivate the OO mind set are still quite compelling. This is the book
to get if you are new to the object-oriented world (Prentice Hall,
ISBN 13-629031-0). Available in French as "Conception et Programmation
par Objets" (90/10 InterEditions, ISBN 2-7296-0272-0) and in German as
"Objektorientierte Softwareentwicklung (Hanser, ISBN 3-446-15773-5).
Also by Dr. Meyer, "Eiffel: The Language", 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) (Prentice Hall, ISBN
13-247925-7). Available in French as "Eiffel, le langage" (94/10
InterEditions, ISBN 2-7296-0525-8).
Dr. Meyer and Jean-Marc Nerson have edited "Object-Oriented
Applications". It includes an introduction to Eiffel technology
followed by seven in-depth descriptions of large applications written
in Eiffel. (Prentice Hall, ISBN 13-013798-7)
Robert Switzer has written "Eiffel: An Introduction". This is a very
clear and concise Eiffel primer, with many code fragments and two
substantial Eiffel applications. (Prentice Hall, ISBN 13-105909-2).
Available in French as "Introduction a Eiffel" (Masson, ISBN
2-225-84-656-1)
ISE distributes a set of 6 video lectures entitled "Object-Oriented
Software Construction", taught by Bertrand Meyer. These provide an
overall introduction to the method and use ISE Eiffel 3 to illustrate
the concepts.
Frieder Monninger's book "Eiffel: Objektorientiertes Programmieren in
der Praxis" is a very down-to-earth Eiffel handbook in German. (Heise,
ISBN 3-88229-028-5).
Bertrand Meyer's "Reusable Software: The Base Object-Oriented
Component Libraries" (Prentice Hall, ISBN 0-13-245499-8, about 530
pages) describes principles of library design and the taxonomy of
fundamental computing structures. Serves as a manual for the
EiffelBase libraries.
Bertrand Meyer's "An Object-Oriented Environment: Principles and
Application" (Prentice Hall, ISBN 0-13-245507-2, 240 pages) describes
the ISE EiffelBench environment as well as the "Melting Ice"
compilation technology and the EiffelBuild GUI application builder.
Richard Wiener's "Software Development Using Eiffel: There can be life
other than C++" (Prentice-Hall, ISBN 0-13-100686-X) is a useful book
(full of serious code samples) for those with a grounding in another
OO language.
A book by Kim Walden and Jean-Marc Nerson, "Seamless Object-Oriented
Software Architecture: Analysis and Design of Reliable Systems",
describes the BON method in detail (Prentice Hall, ISBN
0-13-031303-3).
Pete Thomas and Ray Weedon's "OO Programming in Eiffel" is a very
comprehensive Eiffel tutorial and textbook, with a solid "Abstract
Data Type" approach (Addison-Wesley, ISBN 0-201-59387-4).
Another book called "OO Programming in Eiffel" is by Robert Rist and
Robert Terwilliger, and is a textbook with an emphasis on design.
(Prentice-Hall, ISBN 0-13-205931-2).
Bertrand Meyer's "Object Success" is a manager's guide to object
orientation, its impact on the corporation and its use for
re-engineering the software process (Prentice-Hall, ISBN
0-13-192833-3).
Macmillan publishes John Tyrrell's inexpensive and very approachable
textbook "Eiffel Object-Oriented Programming" (ISBN 0-333-64554-5).
"Object-Oriented Software Engineering with Eiffel"
By Jean-Marc Jezequel, Addison-Wesley Eiffel in Practice Series
ISBN 0-201-63381-7 * Paperback * 368 pages * ) 1996
There is also a white paper titled 'Eiffel: A Manager's Perspective'
which provides a quick introduction to Eiffel and the benefits it
brings to the software development process. For a free copy, send your
name and postal address to tower@twr.com
----------
Q08) Are any magazines or newsletters available concerning Eiffel?
Eiffel Outlook is a bi-monthly journal devoted to Eiffel, published
since 1991. Topics cover all areas of interest to the Eiffel
community.
Subscriptions, trial subscriptions and back issues are available from:
SIG Computer in Germany
Everything Eiffel in the UK & France
Simon Parker in Ireland
IMSL in Japan
Enea Data in Sweden
Tower Technology in the USA and all other countries
Details are available at <http://www.cm.cf.ac.uk/Tower/Outlook.html>
or by sending email to <outlook@twr.com>.
ISE produces a newsletter "Eiffel World". Subscriptions are free
(email your request to info@eiffel.com). Individual copies are
available from:
Cybertech in Argentina
Class Technology in Australia
Jay-Kell Technologies in Canada
SOL in France
SIG Computer in Germany
Eiffel Ireland in Ireland
Etnoteam in Italy
Information & Math Science Lab
Software Research Associates in Japan
Chromasoft in Mexico
Science OO Products & Systems in the Netherlands
Objective Methods in New Zealand
Ruperez & Associates in Spain
Enea Data in Sweden
Abstraction in Switzerland
Everything Eiffel in the UK
Also, EiffelWorld is now available on-line! This is your first
quarterly reminder to visit the EiffelWorld Online magazine at
http://www.eiffel.com/doc/eiffelworld/5.2
If you're interested in Software Design Patterns you may like to
subscribe to the Eiffel Patterns mailing list. Send email to:
e-patterns-request@cbr.dit.csiro.au
----------
Q09) Where can I find Eiffel on the World-Wide-Web?
An Eiffel home page is held on the University of Wales College of
Cardiff's server at http://www.cm.cf.ac.uk/CLE/. Vendor websites are
listed in Q16.
----------
Q10) Where can I get an Eiffel editor or emacs-mode?
Franck Arnaud's Eiffel extension to the Windows/WindowsNT programmers
editor Codewright from Premia allows you to see Eiffel code in colour,
has smart indenting and a few templates. Available by anonymous FTP
from ftp://ftp.cm.cf.ac.uk/pub/eiffel/tools/cweiffel.zip
The WINEDIT shareware programmer's editor offers colour syntax
highlighting, works with Eiffel/S under MS-Windows, and is available
from:
ftp://src.doc.ic.ac.uk/computing/systems/ibmpc/windows3/programr/we-30d.zip
and ftp://gatekeeper.dec.com/.f/micro/msdos/win3/programr/we-30d.zip
Alan Philips' free Programmers File Editor also works with Eiffel/S
under MS-Windows, has templates but not syntax highlighting, available
from ftp://ftp.demon.co.uk/pub/ibmpc/windows/editors/pfe0507.zip
Tower Technology Corporation supplies an Eiffel 3 emacs mode that
supports syntax-directed highlighting, auto-indentation and is easily
customized for font use, color and indentation amounts. It comes as
part of the TowerEiffel system, but is also available free for anyone
who requests it. Send email to elisp@atlanta.twr.com to get the latest
version.
----------
Q11) 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.
ISE supports BON with its EiffelCASE tool.
----------
Q12) How large are typical Eiffel executables?
(How large are typical C executables?)
In general, the size of an executable depends on the compiler used.
Thus, a good Eiffel compiler would produce good C code by removing
dead code such that a C executable is not smaller than an Eiffel
executable. This is true of SmallEiffel and ISE Eiffel compilers.
Also, I think this is similar for others like Tower Eiffel and SIG
Eiffel compilers.
Interestingly, Eiffel applications seem to grow less rapidly as new
capabilities are added. Reuse does help out tremendously in this
regard. A good Eiffel compiler allows large applications to be smaller
than equally functional applications written in C.
Note that leaving assertion checking in the code increases the size of
applications a lot. Despite this, many of us prefer that they remain
throughout development. Some even deliver a PRECONDITIONS-only version
of their applications to their early customers.
----------
Q13) Are there standards for the Eiffel language?
The definition of the Eiffel language is in the public domain. This
definition is controlled by NICE, the Non-profit International
Consortium for Eiffel. This means that anyone or any company may
create a compiler, interpreter, or whatever having to do with Eiffel.
NICE reserves the right to validate that any such tool conforms to the
current definition of the Eiffel language before it can be distributed
with the Eiffel trademark. (i.e. advertised as an "Eiffel" compiler.)
The Eiffel trademark is owned and controlled by NICE. NICE is using
Bertrand Meyer's book, "Eiffel: The Language" (2nd Printing), as the
initial definition of the language.
The NICE board of directors for 1995 consists of Christine Mingins
(chair), Bertrand Meyer (treasurer), Simon Parker (secretary) and Paul
Johnson.
In June 1995 NICE published the first version (called "Vintage 95") of
the Eiffel Library Standard. Those parts of an Eiffel application that
use only the standard classes and features should run with minimal
change on any compiler supporting ELS-95.
NICE (Nonprofit International Consortium for Eiffel)
45 Hazelwood
Shankill
Co Dublin
Republic of Ireland
TEL: +353 1 282 3487
email: nice@atlanta.twr.com
----------
Q14) How fast do Eiffel applications run?
Early versions of Eiffel were slow. Recent implementations have
improved dramatically. However, to achieve maximum performance under
any Eiffel implementation, run-time assertion monitoring must be
switched off. (But see Q12 on when to switch assertions on or off.)
It's hard to generalise, but compared to C++, simple
computation-intensive applications will run perhaps 15% slower. Large
applications are often dominated by memory management rather than
computation. ISE recently demonstrated that by simply adding a call to
the garbage collector's "full-collect" routine at a time when there
were known to be few live objects, performance became dramatically
faster than a corresponding C++ version.
----------
Q15) Are there any Eiffel user groups?
International Eiffel User Group
Darcy Harrison - Attention: IEUG
ISE Inc.
270 Storke Road, Suite 7
Goleta, CA 93117, USA
TEL (805) 685-1006
FAX (805) 685-6869
darcyh@eiffel.com
UK & Ireland Eiffel Interest Group (currently inactive)
GUE, Groupe des Utilisateurs Eiffel (France)
Jean-Marc Nerson
104 rue Castagnary, 75015 Paris
TEL +33 1 45 32 58 80
FAX +33 1 44 32 58 81
marc@eiffel.fr
(meets every 2 months or so)
TowerEiffel User's Group
Private cyberspace mailing list for supported Tower customers with
meetings coinciding with major OO Conferences and Events.
----------
Q16) Where can I get Eiffel products and services?
These vendors, resellers and suppliers of Eiffel training and
consultancy are listed in alphabetical order:
Argentina
Cybertech
Systens Integration for CIM
Suarez 1281, Third Floor,Apt.A
CP-1288 Buenos Aires
TEL +54 1 28 1950
FAX +54 1 322 1071 or 963 0070
Australia
Class Technology Pty. Ltd.
PO Box 2674
North Sydney NSW 2060
TEL +61 2 9922 7222
FAX +61 2 9922 7703
email info@class.com.au
Canada
Jay-Kell Technologies, Inc.
48 Lakeshore Road, Suite #1
Pointe Claire, Quebec
Canada H9S 4H4
TEL +51 4 630 1005
FAX +51 4 630 1456
France
SOL
104 rue Castagnary
75015 Paris
TEL +33 1 45 32 58 80
FAX +33 1 45 32 58 81
email eiffel@eiffel.fr
Germany
Feinarbeit
Altenbraker Strasse 4
D-12053 Berlin
TEL +49 30 6215827
FAX +49 30 6215863
email langmack@netmbx.netmbx.de
SIG Computer GmbH
Zu den Bettern 4
D 35619 Braunfels, Germany
TEL +49 6472 2096
FAX +49 6472 7213
email eiffel@eiffel.de
www http://www.sigco.com/
Jan Willamowius
Semperstr. 1
D-22303 Hamburg
Hamburg, Germany
Tel: +49 40-2806209
Email: jan@janhh.shnet.org
WWW: http://swt1.informatik.uni-hamburg.de/~1willamo/dl.html
Ireland
Eiffel Ireland
45 Hazelwood
Shankill
Co Dublin
TEL +353 1 282 3487
email sparker@eiffel.ie
www http://www.eiffel.ie/Eiffel/
India
Sritech Information Technology
744/51 2nd Floor
10 Mian Road, 4th Block
Jayanagar, Bangalore, India 560011
TEL +91 812 640661
FAX +91 812 643608
Italy
EtnoTeam
Via Adelaide Bono Cairoli 34
20217 Milano
TEL +39 2 261621
FAX +39 2 26110755
email sales@etnomi.it
Japan
Information and Math Science Lab Inc.
2-43-1, Ikebukuro, Toshima-ku
Tokyo 171
email fushimi@idas.imslab.co.jp
TEL +81 3 3590 5211
FAX +81 3 3590 5353
Software Research Associates
1-1-1 Hirakawo-Cho
Chiyoda-ku Tokyo 102
TEL +81 3 3234 8789
FAX +81 3 3262 9719
email sugita@sra.co.jp
Mexico
Cromasoft SA de CV
Mazatlan 161
Col Condesa, 06140 Mexico
TEL +52 5 286 82 13
FAX +52 5 286 80 57
email claudio@croma.sunmexico.sun.com
The Netherlands
SOOPS
Sarphatistraat 133
NL-1018 GC Amsterdam, The Netherlands
TEL +31 20 525 6644
FAX +31 20 624 6392
email A731CISK@HASARA11.BITNET
New Zealand
Objective Methods Ltd
PO Box 17356 (77 Chamberlain Rd)
Karori, Wellington, New Zealand
TEL +64 4 476 9499
FAX +64 4 476 9237 or 8772
email dkenny@swell.actrix.gen.nz
Russia
SIG Computer, Germany has a branch office in Moscow.
email eiffel@sigcomp.msk.su
Spain
Eiffel Iberica
Aptdo 1646
20080 San Sebastian
TEL +34 943 471906
email ean@sc.ehu.es
Ruperez & Associates
c/San Bartolome 21, 5F
20001 San Sebastian
TEL +34 43 461801
email jipferur@si.ehu.es
Sweden
Enea Data
Box 232, Nytorpsvagen 5
S-183 23 Taby
TEL +46 8 792 25 00
FAX +46 8 768 43 88
email eiffel@enea.se
Switzerland
Abstraction
18 Faubourg de l'Hopital
2000 Neuchatel
TEL +41.38.25.04.93
FAX +41.38.259.857
email silberstein@clients.switch.ch
Objectif Concept
Passage Cour-Robert 5
CH 1700 Fribourg
TEL +41 37 232977
FAX +41 37 464889
United Kingdom
Eon Software
19 Stapleton Road
Heddington, Oxford OX3 7LX
TEL +44 865 741452
email ian@eonsw.demon.co.uk
Everything Eiffel
6 Bambers Walk
Wesham PR4 3DG
England
TEL & FAX +44 1772 687525
email rogerb@eiffel.demon.co.uk
United States of America
Interactive Software Engineering, Inc
270 Storke Road, Suite 7
Goleta, CA 93117
TEL 805-685-1006
FAX 805-685-6869
email info@eiffel.com
www http://www.eiffel.com/
Tower Technology Corporation
1501 Koenig Lane
Austin, TX 78756 USA
TEL 512-452-9455
FAX 512-452-1721
email: tower@twr.com
www http://www.twr.com/
ZumaSoft
6235 Paseo Canyon Drive
Malibu, California 90265, USA
TEL & FAX +1 310 457-6263
email tstevens@netcom.com
----------
Q17) Are there any conferences for Eiffel users?
The conferences listed here are not just for Eiffel. Eiffel shares the
spotlight with other OO languages including C++ and Smalltalk.
Feb 26 - 29 1996
TOOLS Europe, Paris France
Jul 29 - Aug 2 1996
TOOLS USA, Santa Barbara California
TOOLS is the major international conference devoted to the
applications of OO technology. Other events, such as Eiffel User Group
meetings or NICE meetings are often held in conjunction with TOOLS.
TOOLS Conferences
PO Box 6863, Santa Barbara, CA 93160, USA
TEL (805) 685 1006, FAX (805) 685 6869
email tools@tools.com
----------
Q18) Why do most 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 (an Eiffel-to-C compiler is
perhaps 4 to 5 times more difficult to create than a native Pascal
compiler).
Compiling Eiffel to C seems to work well under Unix. C is sometimes
thought of as the native code of Unix.
On the other hand, C is not universal on other platforms, and the
Eiffel purchaser may need to buy a C compiler as well, and possibly
replace it if the supported C compilers change with new versions of
the Eiffel compiler.
With a native-code compiler, you'd get somewhat better throughput and
the potential for smaller executables and slightly better performance.
You'd also get a higher price and an even longer wait for Eiffel to
show up on other than the leading market share machines.
----------
L01) What features does Eiffel have?
Eiffel is a pure object-oriented language. Its modularity is based on
classes. It stresses reliability, and facilitates design by contract.
It brings design and programming closer together. It encourages 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, and deferred classes
for high-level design and analysis.
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/
----------
L02) 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. Here is a summary of the major
changes:
1. Changes between the publication of "Object-Oriented Software
Construction" in 1988, and the release of Eiffel 2.3:
- Constrained genericity enables a generic class to restrict its
generic parameters to the descendants of a given class
- The "indexing" clause allows information about a class to be
recorded for extraction by archival, browsing and query tools
- The assignment attempt operator "?=" provides a way to make
type-safe assignments going against the inheritance hierarchy
- User-defined infix and prefix operator features
- Expanded types support composite objects without dynamic
allocation, and with value semantics
- The "obsolete" clause for smooth library evolution
- The "unique" keyword for implicitly-assigned integer codes
- The multi-branch instruction (similar to a case statement)
- The boolean operator for implication ("implies")
2. Changes with the introduction of Eiffel Version 3:
- The feature adaptation subclause must now be terminated with
"end"
- Semicolons as instruction separators are optional
- Groups of features are bracketed by a feature clause. All
features are exported unless the feature clause specifies a
restriction. The repeat subclause is no longer needed, because
inherited features keep the original export status they had in
the parent unless they are redefined, or are the subject of an
export subclause in the feature adaptation clause.
- Preconditions can only be replaced by weaker ones, postconditions
can only be replaced by stronger ones. This is now enforced by
the language through the use of "require else" in preconditions
and "ensure then" in postconditions.
- Ambiguities in repeated inheritance are resolved by a "select"
clause.
- A feature can no longer be replicated and redefined in the same
feature adaptation clause, however the same effect can be
achieved through repeated inheritance
- Two or more features may be defined at the same time (e.g. "f1,
f2 is...").
- The keyword "frozen" before a feature name prohibits redefinition
of the feature in descendants
- In an anchored declaration, the anchor may now also be a formal
argument of the enclosing routine
- A class may have zero, one or more creation procedures,
designated with the "creation" keyword. A new creation syntax
using the "!!" symbol allows the appropriate creation procedure
to be specified. It is also possible to directly create an object
of any type which conforms to the entity to which it is being
attached.
- The meaning of dot notation has been made more uniform, and
alternative constructs have been provided for the special
language-defined features that previously used dot notation:
x.Create is now !! x
y.Clone(x) is now y := clone(x)
x.Forget is now x := Void
x.Void is now x = Void
x.Equal(y) is now equal(x, y)
- Manifest arrays can be specified, for example
<<"Jan", "Feb", "Mar">>
which also provides a way to pass a variable number of arguments
to a routine.
- The command-line parameters are made available to the creation
procedure of the root class as an array of strings.
- A default rescue procedure called default_rescue may be defined
and inherited.
- A class may be declared to be an expanded class, in which case
any type based on that class will be expanded.
- An object may no longer contain a reference to an expanded object
that is a sub-object of another object. Instead, upon assignment
of an expanded object to a non-expanded object, the expanded
object will be cloned, and a reference to the newly-cloned object
will be stored in the non-expanded object.
- The operator "div" has been replaced by "//", and the operator
"mod" has been replaced by "\\".
3. Changes between first and second printings of "Eiffel: The Language"
- New basic types INTEGER_REF, REAL_REF, CHARACTER_REF and
BOOLEAN_REF etc have been introduced to provide non-expanded
basic types.
- Introduction of the POINTER type to enable external references to
be passed around in Eiffel programs.
- Calls from Eiffel to external routines no longer implicitly pass
the current object as the first parameter.
There are many other (more minor) changes, which Neil Wilson has
summarized in ftp.cm.cf.ac.uk:/pub/eiffel/Docs in both Microsoft
Rich Text Format and ASCII.
----------
L03) 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 and more.
Contact the vendors for further details.
----------
L04) 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, if a
conjecture by Dr. Meyer bears fruit, the notion of preconditions may
be extended into an important mechanism for the development of
parallel programming.
----------
L05) 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 ancestor. In fact, the descendant object is in every way
also a fully-valid instance of the ancestor 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 ancestor 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.
Sather uses the contravariant rule, but uses separate mechanisms for
subtyping and code reuse and only allows dynamic binding on true
subtypes. This seems to make contravariance work well, but it can
force the Sather programmer to use concrete types when modelling
covariant problems. Concrete types cannot be further subtyped in
Sather, so this can reduce the potential for re-use (in Eiffel, any
type can be further subtyped, but the compiler must check that it is
used validly).
----------
L06) Is it true that there are "holes" in the Eiffel type system?
No. The design of Eiffel makes it possible to catch all type errors at
compile time, so that an Eiffel program cannot abort with a run time
type error.
However, to catch a class of certain more obscure type errors at
compile time, the compiler must analyse the way that classes interact
within the entire system, rather than just looking at each class one
by one.
There is a proposal underway that, if accepted, will allow compilers
to check this class of errors by looking at classes and not at the
whole system.
Because system-wide compile-time validity checking can be complex,
some compilers insert run-time traps for these errors instead, and
some may fail to correctly trap these errors. Ask your Eiffel compiler
vendor how they handle these type problems.
----------
L07) Is there support for concurrency in Eiffel?
Eiffel does not yet support concurrency; neither do current commercial
compilers. However, work on concurrency for Eiffel is a hot research
topic.
For four articles on concurrency facilities for Eiffel, including
Bertrand Meyer's article "Systematic Concurrent Object-Oriented
Programming", see the September 1993 "Communications of the ACM" (Vol.
36, Number 9).
At least one of these articles can also be obtained from ISE's WWW
site (http://www.eiffel.com).
----------
L08) 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 ("multiple polymorphism"), 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 you have to learn.
This is at the expense of reducing the ability of the compiler to trap
mistakes (often 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. There is no
intuitive rule which could be used to disambiguate routine calls where
there is no "nearest" routine.
However, in Eiffel it's easy to write one routine with arguments of
the most general applicable type, then use the assignment attempt
operator to carry out the appropriate operation according to the
run-time type of the arguments (thereby explicitly programming the
disambiguation "rules").
Having said that, the lack of multiple polymorphism does force us to
write some common mathematical operations (e.g. matrix math) in an
awkward way, and forces arithmetic expressions to be treated specially
(the "arithmetic balancing rule", ETL p385). But no-one has come up
with a solution which is so simple, elegant and useful that it
improves the quality of Eiffel as a whole.
----------
L09) Why are there no procedural types in Eiffel?
The notion of allowing a routine to be passed as an argument to a
routine is in many people's view incompatible with the OO method. The
definition of object-orientation implies that every operation belongs
to an object type, so one does not manipulate routines just by
themselves.
A possible technique when one feels the need to use a routine argument
is to write a class and include the routine in it. Then (rather than
passing a routine argument) pass an object - an instance of this class
- to which the routine can then be applied. This is a more flexible
approach in the long term. For example, you may later add an "undo"
routine to your routine - containing class, or an attribute such as
"time of last execution".
----------
L10) 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, when it is first called. Thereafter, the "once" function returns
the same Result without re-executing its body.
The "once" function can therefore be used to implement a shared
attribute of reference type (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.
----------
L11) How can I call the parent-class version of a redefined routine?
When an inherited routine is redefined in a child class, is there a
way for the redefined routine to call the version in the parent class?
1) If you are responsible for the design of the parent class, you may
anticipate such a need. You may provide multiple versions of the
same routine body, with some versions frozen (not redefinable):
class PARENT
feature foo, frozen parent_foo is
do
...
end
end
class CHILD
inherit
PARENT
redefine foo
end
feature foo is
do
parent_foo
...
end
end
2) Otherwise, you use repeated inheritance to get two versions of
'foo', and redefine one of them:
class PARENT
feature foo is
do
...
end
end
class CHILD
inherit
PARENT
rename foo as parent_foo
end
PARENT
redefine foo
select foo -- (in case of dynamic binding)
end
feature
foo is
do
parent_foo
...
end
end
----------
L12) Where can I find a comparison between Eiffel and C++?
In Richard Wiener's book "Software Development Using Eiffel: There can
be life after C++" (Prentice-Hall, ISBN 0-13-100686-X).
----------
L13) Are there any destructors in Eiffel?
Eiffel objects are garbage-collected, so that there is no need for the
software developer to worry about whether, how and when to "destruct"
or "free" them in the software text.
Some implementations offer a "free" procedure for programmers who
absolutely want to remove an object manually. Such a procedure is "use
at your own risk" and is not needed in normal Eiffel development.
Coming back to normal usage, the need may arise to ensure that certain
operations will automatically take place whenever the garbage
collector reclaims an object. For example if an Eiffel object
describing a file becomes unreachable and hence is eventually
garbage-collected, you may want to ensure that the physical file will
be closed at that time. Some 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 (so that a smart
GC will of course avoid executing any actual call). But any class may
inherit from MEMORY and redefine 'dispose' to perform appropriate
actions, such as closing a file. Such actions are sometimes called
"finalization". This technique achieves it conveniently.
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 such
as file descriptors, database elements, window system resources etc,
not on Eiffel object structures themselves.
--
o ''' Conrad Taylor o
o (o o) Software Engineer o
o-----oOO--(_)--OOo----- Land Mobile Products Sector o
o The Eiffel Language conradt@comm.mot.com o