Eiffel compatibility options

Introduction

Over the course of several releases, Eiffel Software has introduced a number of options and settings which allow users of EiffelStudio and the Eiffel command line compiler to choose the appropriate level of forward progress and/or backward compatibility for a particular application.

This is a summary of the motivation behind and the meanings of the various compatibility options.

Quick guide to project settings affecting compatibility with older Eiffel code

The table below shows project settings that, depending upon their values, can affect the compilation of Eiffel code produced under older standards. That is, certain values for some of these settings may cause older code to fail to compile due to non-compliance. However, other values may allow you to compile non-compliant code during a period in which you convert that code to the current Eiffel implementation.

Discussion of compatibility issues

Eiffel Software and the wheels of progress

The Eiffel analysis, design, and programming language has remained relatively static since its original specification in the mid-1980's. However, periodically it has become necessary to make certain changes in order to make certain language improvements and to enable new facilities. It is the policy of Eiffel Software, when such changes are made, to ensure that the changes have minimum impact upon existing software. For some changes, that means no impact at all, but for others it means that the new Eiffel is incompatible with the old Eiffel (the so-called "breaking changes" … those changes that break existing code). And that means that existing software will have to be changed to take advantage of the recent changes to Eiffel. Even so, Eiffel Software has been able to ease the transition from old to new by implementing certain compatibility options which allow existing software still to run as in previous versions during periods of transition.

Sources of changes

The Eiffel programming language is standardized under the ISO and ECMA standardization organizations. So, it is not surprising that many of the changes that are implemented by Eiffel Software are driven by the work of the Eiffel standardization committee.

Still, the standard itself is a moving target, and there are always differences between what is in the current standard and what has been implemented by Eiffel Software. Also, only immediately after publication of the standard might there be complete agreement between the standard document itself and the perception of Eiffel by the standard committee. That is to say that a new version of the standard may be published once every few years, but the process of moving the language forward continues in the committee in the meantime.

The diagram below attempts to characterize the relationship among the various factors that define Eiffel.

It is easy to see the overlapping areas. The centermost represents that part of Eiffel that is at once implemented by Eiffel Software, exists in the current published version of the standard, and is anticipated to remain in the standard for the next version.

The other areas represent Eiffel features that are supported by only one or a combination of two of these factors.

Types of changes

There are many different types of changes that can effect existing code. Here are some examples of these.

1. Changes to the Eiffel library classes
   1. Removal or obsoleting of classes or features. Example: {SPECIAL}.make is removed as void-unsafe.
   2. Changing conformance. Example: ARRAYED_LIST no longer conforms to ARRAY.
   3. Changing feature types. Example: {ARRAYED_LIST}.count and {ARRAYED_LIST}.area were changed from attributes to functions.
2. Language keyword changes
   1. A word that was once a keyword is no longer a keyword (potentially allowing the word to be used as an identifier, and affecting software using it as a keyword). Example: indexing is no longer a keyword.
   2. A word that was not a language keyword in previous versions, becomes one in the current version (potentially breaking any code that used that word as an identifier). Example: attached
   3. A keyword (or notation) used in a particular context is retired from that context in favor of a more appropriate keyword. (potentially affecting all software using the old keyword in that context). Example: indexing is retired in favor of note.
   4. The usage of an existing keyword in a new context (usually has no effect on existing software). Example: as used in attached syntax for object test (in addition to its traditional role in the rename part of the inherit clause.)
3. Language construct changes
   1. Addition of new constructs or extensions to existing constructs. Example: iteration form of the loop construct.
   2. Changes to existing constructs. Example: Object test syntax change: attached {T} expr as u versus {u: T} expr
   3. Removal of obsolete constructs.

Types of compatibility options

EiffelStudio and Eiffel compiler options

These "mode" options are selected when EiffelStudio is started up or when the command line Eiffel compiler is invoked. The following two mode options were introduced in version 6.3 on the eve of implementing void-safety as an integral feature of Eiffel. The mode options were intended to help developers deal with the changes to the Eiffel libraries for void-safety.

• -compat runs EiffelStudio or the Eiffel compiler in "compatibility mode" so that compilation will use libraries that are compatible with older versions of Eiffel.
• -experiment runs EiffelStudio or the Eiffel compiler in "experimental mode" so that compilation will use libraries based on an upcoming version of Eiffel.

Implicit here is that there is also a "default" mode which is invoked when neither of compatibility nor experimental mode is used. Default mode assumes a "current" set of libraries.

Also, implied by these modes is a progression of their meanings over time. That is, as time passes and language changes are reflected in Eiffel Software's products, the "experimental" mode of today will likely be the "default" mode of tomorrow. And the "default" mode of today may become the "compatible" mode of tomorrow.

Project settings

These options are set in the EiffelStudio Project Settings dialog box.

The most important of these is the Syntax level variant setting. You can choose among a set of syntax level variants that let you control how the compiler views certain language changes. So, for example, if you are compiling classes that contain obsolete keywords, you would set the Syntax setting to the Obsolete syntax variant.

Bear in mind that the detail meanings of the various syntax variants may change from version to version. So, it's a good idea periodically to check the syntax level variant settings by version.

Compatibility tools

The syntax updater

The syntax updater is located in the EiffelStudio "tools" folder. It is a command line utility that will update certain syntax elements from obsolete syntax to current syntax. The syntax updater was introduced with EiffelStudio version 6.4.

The tool makes the following updates to existing code:

1. Replaces obsolete "!!" syntax with create keyword syntax.
2. Replaces obsolete keyword creation with create.
3. Removes obsolete keyword is after routine signatures.
4. Replaces obsolete keyword is in constants with "=" (e. g., "i: INTEGER is 5" becomes i: INTEGER = 5").
5. Replaces obsolete keyword indexing with note.
6. Replaces the June 2006 Standard object test syntax (e. g., "{x: T} exp") with the committee-approved provisional standard syntax (e. g., "attached {T} exp as x").
7. Replaces obsolete non-object feature call syntax with current syntax (e. g., "feature {X}.f" becomes "{X}.f").
8. Replaces attached and detachable type markers from June 2006 Standard with committee-approved provisional standard syntax (e. g., "x: !T" becomes "x: attached T" and "x: ?T" becomes "x: detachable T").