Celestin Apprentice 5/Apprentice-Release5.iso/Environments/SmallEiffel 0.3.3/SmallEiffel PPC/docs/Eiffel FAQ

Text File | 1996-05-12 | 46.8 KB | 1,301 lines | [TEXT/dosa]

*** NEW FAQ MAINTAINER ***

This is the last edition of the comp.lang.eiffel FAQ that I will be
posting.

The new maintainer is Conrad Taylor (email [e-mail]),
who has kindly agreed to take over this task.

Thanks to all those who have contributed over the last few years.

Regards,
Roger Browne

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
([e-mail]).

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 Roger Browne. 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 [e-mail] with this
message body:

   send Eiffel eiffel-faq

----------

CONTENTS

Changes since the last posting:

Added a what's new section to the FAQ to inform the Eiffel Community
of new software releases of Eiffel related products and services.

   N01) New OO/Eiffel book from A-W
   N02) SmallEiffel Eiffel Compiler

What's New:

   N01) New OO/Eiffel book from A-W
   N02) SmallEiffel Eiffel Compiler

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)   New OO/Eiffel book from A-W

This new book entitled "Object-Oriented Software Engineering in Eiffel"
by Jean-Marc Jezequel in the "Addison-Wesley Eiffel in Practice Series"
(Series Editor, Bettrand Meyer).  The book focuses on the use of Eiffel
in the large mission critical systems.

>From the back cover of the book:

   An indispensable resource for anyone working with Eiffel, this
   up-to-date  guide  provides  full  coverage of the most recent
   version of the language, focusing on Eiffel's practical use in
   the  development  of large, mission-critical software systems.

   In addition to a comprehensive description of Eiffel's  syntax
   and  semantics,  you  will  find in-depth information on style
   guides, analysis & design, design patterns, and validation and
   testing.  Descriptions  and comparisons of available compilers
   and  libraries will help you decide which  Eiffel  tools  best
   fit  your  development needs. The book even includes an Eiffel
   resource guide.

   The book's most notable feature is its three large-scale  case
   studies   that  demonstrate  Eiffel  in  action,  illustrating
   implementation techniques and showcasing  Eiffel's  power  and
   effectiveness  in  three  different realms: The MIS world, the
   embedded systems/telecommunications  world,  and  the  numeric
   world.

   By reading this book you will not only obtain a  knowledge  of
   the  mechanics  of  Eiffel programming, but you will also come
   away with an understanding of Eiffel's role in  the  field  of
   object-oriented  technology  and  a  sense  of  the language's
   strong potential in large software development.

OBTAINING THE BOOK

"Object-Oriented  Software  Engineering  in  Eiffel"  by  Jean-Marc
Jezequel  (ISBN 0-201-63381-7, 340+ pages, soft cover) is available
from ISE for US$ 40   plus applicable tax (CA residents, 8.25%) and
shipping  (in the USA, $5   for UPS Ground per book, $15    for UPS
2nd Day Air. Canada: $15  for UPS Ground per book $25   for UPS 2nd
Day  Air.   Other:  $40  for  UPS  International Air, or Airmail at
cost.).  It is also available in technical bookstores worldwide.

You can order  by phone, fax, or email from ISE using the addresses
below.   A comprehensive list of Eiffel-related books and
documentation is available on ISE's web site:

           http://www.eiffel.com/doc/documentation.html

Interactive Software Engineering Inc.
270 Storke Rd, Suite 7, Santa Barbara, CA 93117 USA
Phone [phone], Fax [phone]

----------

N02)   SmallEiffel Eiffel Compiler

SmallEiffel is a free Eiffel compiler distributed under the terms
of the GNU General Public License as published by the Free Software
Foundation.

SmallEiffel is the fruit of a research project done at
CRIN (Centre de Recherche en Informatique de Nancy).
SmallEiffel is already used (and tested) by students of the
University Henri Poincare' at Nancy (FRANCE).
We are using Eiffel as a first langage for teaching OOP
since 1990 (SmallEiffel is used since september 1995).

Brief description of SmallEiffel :

- Target code is ANSI C. The compiler is fully written in
  Eiffel (bootstrapped and purifyed).
- SmallEiffel Works on all UNIX-like platform including LINUX.
  Code is easely portable on other platforms (students have
  already run Smalleiffel on OS2 and DOS).
- SmallEiffel uses a new technology of compilation (we have
  sent a submission for OOPSLA96).
  SmallEiffel replace a lot of late binding calls by static
  hard calls (84% of calls on the compiler code itself are
  replaced).

Try SmallEiffel by youself.
You can download SmallEiffel at :

    ftp://ftp.loria.fr/pub/loria/genielog/SmallEiffel

----------

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)

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?

ISE's "Free Eiffel for Windows" is a TTY-based, menu-driven Eiffel
interpreter. It runs under Windows 3.1 & Windows NT, and is
available by FTP from SimTel mirror sites in SimTel/win3/eiffel
in files fre3r2d1.zip to fre3r2d6.zip inclusive.

SIG Computer's "Eiffel/S 1.3s" is a shareware version of their Eiffel
compiler for DOS, Unix and Macintosh, 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/

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 ([e-mail]).

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 Universitat
   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
   ([e-mail]).

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/
ftp://gatekeeper.dec.com/pub/plan/eiffel/usenet/ (to September 1992 only)

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 "Objektorientiert
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).

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 [e-mail]

----------

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
<[e-mail]>.

ISE produces a newsletter "Eiffel World". Subscriptions are free (email
your request to [e-mail]). 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 or 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

If you're interested in Software Design Patterns you may like to subscribe
to the Eiffel Patterns mailing list. Send email to:

   [e-mail]

----------

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 [e-mail] 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?)

Seriously, Eiffel does impose a minimum size which is large since even
trivial Eiffel applications bring in a lot of classes. So, a simple program
like "Hello World" will create a relatively large executable.

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: [phone]
email: [e-mail]

----------

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.

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 [phone]
FAX [phone]
[e-mail]

UK & Ireland Eiffel Interest Group (currently inactive)

GUE, Groupe des Utilisateurs Eiffel (France)
Jean-Marc Nerson
104 rue Castagnary, 75015 Paris
TEL [phone]
FAX [phone]
[e-mail]
(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:

Abstraction
18 Faubourg de l'Hopital
2000 Neuchatel, Switzerland
phone [phone]
fax [phone]
email [e-mail]

Class Technology Pty. Ltd.
PO Box 2674
North Sydney NSW 2060, Australia
TEL [phone]
FAX [phone]
email [e-mail]

Cromasoft SA de CV
Mazatlan 161
Col Condesa, 06140 Mexico
TEL [phone]
FAX [phone]
email [e-mail]

Cybertech
Systens Integration for CIM
Suarez 1281, Third Floor,Apt.A
CP-1288 Buenos Aires, Argentina
TEL [phone]
FAX [phone] or 963 0070

Eiffel Iberica
Aptdo 1646, 20080 San Sebastian, Spain
TEL [phone]
email [e-mail]

Eiffel Ireland
45 Hazelwood
Shankill
Co Dublin, Ireland
TEL [phone]
email [e-mail]
www http://www.eiffel.ie/Eiffel/

Enea Data
Box 232, Nytorpsvagen 5
S-183 23 Taby, Sweden
TEL [phone]
FAX [phone]
email [e-mail]

Eon Software
19 Stapleton Road
Heddington, Oxford OX3 7LX, UK
TEL [phone]
email [e-mail]

EtnoTeam
Via Adelaide Bono Cairoli 34
20217 Milano, Italy
TEL [phone]
FAX [phone]
email [e-mail]

Everything Eiffel
6 Bambers Walk
Wesham PR4 3DG
England
TEL & FAX [phone]
email [e-mail]

Feinarbeit
Altenbraker Strasse 4
D-12053 Berlin, Germany
tel [phone]
fax [phone]
email [e-mail]

Information and Math Science Lab Inc.
2-43-1, Ikebukuro, Toshima-ku
Tokyo 171, Japan
email [e-mail]
TEL [phone]
FAX [phone]

Interactive Software Engineering, Inc
270 Storke Road, Suite 7
Goleta, CA 93117
TEL [phone]
FAX [phone]
email [e-mail]
www http://outback.eiffel.com/

Jay-Kell Technologies, Inc.
48 Lakeshore Road, Suite #1
Pointe Claire, Quebec
Canada H9S 4H4
TEL [phone]
FAX [phone]

Objectif Concept
Passage Cour-Robert 5
CH 1700 Fribourg, Switzerland
TEL [phone]
FAX [phone]

Objective Methods Ltd
PO Box 17356 (77 Chamberlain Rd)
Karori, Wellington, New Zealand
TEL [phone]
FAX [phone] or 8772
email [e-mail]

Ruperez & Associates
c/San Bartolome 21, 5F
20001 San Sebastian, Spain
TEL [phone]
email [e-mail]

SIG Computer GmbH
zu den Bettern 4
D 35619 Braunfels, Germany
TEL [phone], FAX [phone]
email [e-mail]
(cyrillic email [e-mail])
www http://www.sigco.com/

Software Research Associates
1-1-1 Hirakawo-Cho
Chiyoda-ku Tokyo 102, Japan
TEL [phone]
FAX [phone]
email [e-mail]

SOL
104 rue Castagnary
75015 Paris, France
TEL [phone]
FAX [phone]
email [e-mail]

SOOPS
Sarphatistraat 133
NL-1018 GC Amsterdam, The Netherlands
TEL [phone]
FAX [phone]
email [e-mail]

Sritech Information Technology
744/51 2nd Floor
10 Mian Road, 4th Block
Jayanagar, Bangalore, India 560011
TEL [phone]
FAX [phone]

Tower Technology Corporation
1501 Koenig Lane
Austin, TX 78756 USA
TEL [phone]
FAX [phone]
email: [e-mail]
www http://www.twr.com/

ZumaSoft
6235 Paseo Canyon Drive
Malibu, California 90265, USA
TEL & FAX [phone]
email [e-mail]

----------

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 [phone], FAX [phone]
email [e-mail]

----------

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/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 the 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. This type of
system-wide checking is also necessary for many compiler optimisations.

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).

----------

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.  The 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.

--
-- Roger Browne, 6 Bambers Walk, Wesham, PR4 3DG, UK   | Ph 01772-687525
-- Everything Eiffel: compilers/libraries/publications | [phone]