Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ucsd!hub!eiffel!bertrand From: bertrand@eiffel.UUCP (Bertrand Meyer) Newsgroups: comp.lang.eiffel Subject: Release 2.2 overview (Part 2 of 2) Keywords: Shorter than part 1 Message-ID: <172@eiffel.UUCP> Date: 10 Jul 89 06:26:36 GMT Organization: Interactive Software Engineering, Santa Barbara CA Lines: 85 PART 2 (OF 2) ------------------------------------------- 8 DOCUMENTATION The existing documentation (User's Manual, Library Manual) has been comprehensively updated. A new manual, entitled Eiffel Reference Manual, provides a complete reference on Eiffel as a language. This manual is a first draft and is still subject to extension and refinement. Each library comes with an on-line doc directory containing explanations and examples. As noted above, the graphical library and the browsing facilities are delivered with full-fledged example applications in source form. 9 COMPATIBILITY ISSUES Every effort has been made to ensure that previously correct software would still compile and work exactly as before. Minor problems may, however, arise in two areas: reserved words and feature terminology in the data structure library. 2.2 introduces the following new reserved words: Accept BITS define DOUBLE expanded implies indexing infix inspect obsolete prefix unique when xor Any use of these words as identifier in an existing class will raise an error. This will be corrected by choosing other identifiers. In the data structure library new identifiers have been introduced for many library features. All the old ones, however, have been kept as ``obsolete'' features. This fully protects all client classes against any incompatibility; the only practical consequences are compile-time warnings (5.8) that the end of the world is near unless clients mend their ways. To a large extent, descendants are safe too. In some cases, however, classes that used to be correct will produce compile-time errors because they inherit from two library classes with identically named features, raising a name clash. The likelihood of such an event is increased by the unification of feature terminology (2.6), which implies that many library classes have features using a small number of universal names such as put and item. Such problems will be resolved in a straightforward way by adding adequate rename clauses in the descendant classes raising the clashes. The effort involved should be minimal. Programmers who do not want to make this effort immediately may ensure full library compatibility by specifying the ``2.1'' library directory in the UNIVERSE (or SOURCE) entry of the System Description File. This way old software will compile exactly as before. It is of course advisable to migrate as soon as possible to the new libraries. -- -- Bertrand Meyer bertrand@eiffel.com