Compatibility Conditions

2 Compatibility Conditions

2.1 Definitions

2.1.1 Required Classes: In this Standard, the phrase "Required Classes" denotes a set of classes whose names are those listed in section 3.
2.1.2 Required Flatshort Form: In this Standard, the phrase "Required Flatshort Forms" denotes the flatshort forms given for the Required Classes in section 3.
2.1.3 Flatshort Compatibility: In this Standard, a class is said to be Flatshort-Compatible with one of the short forms given in this Standard if it satisfies the conditions given in section 2 of this Standard.
2.1.4 Required Ancestry Links: In this Standard, the expression "Required Ancestry Links" denotes the inheritance links specified in section 4 of this Standard.

[The term "Ancestry" is used rather than "Inheritance" because the required links may be implemented by indirect rather than direct inheritance, except for ANY which must be a direct heir of GENERAL as per rule 4.2.]

2.2 Kernel compatibility

2.2.1 Definition

An Eiffel implementation will be said to be kernel-compatible if and only if it includes a set of classes satisfying the following five conditions:

2.2.1.1: For each of the Required Classes, the implementation includes a class with the same name.
2.2.1.2: All the Required Ancestry Links are present between these classes.
2.2.1.3: The flatshort form of each one of these classes is Flatshort-Compatible with the corresponding Required Flatshort Form.
2.2.1.4: All the dependents of the Required Classes in the implementation are also included in the implementation.
2.2.1.5: None of the features appearing in the Required Flatshort Forms appears in a Rename clause of any of the implementation's Required Classes.

[These conditions allow a kernel-compatible implementation to include inheritance links other than the ones described in this Standard; condition 2.2.1.4 indicates that for any such link the additional proper ancestors must also be provided by the implementors, since the dependents of a class include its parents.]

[Condition 2.2.1.4 guarantees that if a feature name appears in this Standard both in the Flatshort form of a Required Class and in the flatshort form of one of its proper ancestors, it corresponds to the same feature or to a redefinition of it.]

2.3 Flatshort Conventions

2.3.1 Definition

In the process of assessing for Flatshort Compatibility a class C from a candidate implementation, the following ten conventions, which have been applied to the Required Flatshort Forms as they appear in this Standard, shall be applied:

2.3.1.1: No feature shall be included unless it is generally available (as defined in Eiffel: The Language, page 100) or is a general creation procedure (as defined in Eiffel: The Language, page 285).
2.3.1.2: The Creation clause of the flatshort specification shall include the full specification of all general creation procedures of C.
2.3.1.3: Any feature of C not inherited from GENERAL shall be included in one of the Feature clauses.

[As a consequence of the last two rules the specification of a creation procedure that is also generally exported will appear twice: in the Creation clause and in a Feature clause. Also note that the "features of a class" include inherited as well as immediate features, so that all features inherited from an ancestor other than GENERAL must appear in the flatshort form.]

2.3.1.4: A feature f from GENERAL shall be included if and only if C redeclares f.
2.3.1.5: The header comment of any inherited feature coming from a Required Class A and having the same name in C as in A shall end with a line of the form:

-- (From A.)

2.3.1.6: The header comment of any inherited feature coming from a Required Class A and having a name in C different from its name x in A shall end with a line of the form:

-- (From x in A.)

[The comments defined in the last two rules are applicable regardless of whether C redeclares the feature.]

2.3.1.7: If deferred, C shall appear as deferred class.
2.3.1.8: Any deferred feature of C shall be marked as deferred.
2.3.1.9: In case of precondition redeclaration, the successive preconditions shall appear as a single Precondition clause, separated by semicolons.
2.3.1.10: In case of postcondition redeclaration, the successive preconditions shall appear as a single Postcondition clause, separated by and then.

2.4 Flatshort Compatibility

2.4.1 Definition

A class appearing in an Eiffel implementation is said to be Flatshort-Compatible with a class of the same name listed in this Standard if and only if any difference that may exist between its flatshort form ic and the flatshort form sc of the corresponding class as it appears in section 5, where both flatshort forms follow the conventions of section 2.3, belongs to one of the following eleven categories:

2.4.1.1: A feature that appears in ic but not in sc, whose Header_comment includes, as its last line, the mention:

-- (Feature not in Kernel Library Standard.)

2.4.1.2: An invariant clause that appears in ic but not in sc.
2.4.1.3: For a feature that appears in both ic and sc, a postcondition clause that appears in ic but not in sc.
2.4.1.4: For a feature that appears in both ic and sc, a precondition in sc that implies the precondition in ic, where the implication is readily provable using rules of mathematical logic.
2.4.1.5: For a feature that appears in both ic and sc, a postcondition or invariant clause in ic that implies the corresponding clause in sc, where the implication is readily provable using rules of mathematical logic.
2.4.1.6: A difference between the Tag_mark of an Assertion_clause in ic and its counterpart in sc.
2.4.1.7: For a feature that appears in both ic and sc, an argument type in sc that is different from the corresponding type in ic but conforms to it.
2.4.1.8: For a feature that appears in both ic and sc, an argument type in ic that is different from the corresponding type in sc but conforms to it.
2.4.1.9: For a feature that appears in both ic and sc, a line that appears in the Header_comment of ic but not in that of sc.
2.4.1.10: An Index_clause that appears in ic but not in sc.
2.4.1.11: A difference regarding the order in which a feature appears in ic and sc, the Feature_clause to which it belongs, the Header_comment of such a Feature_clause, or the presence in ic of a Feature_clause that has no counterpart in sc.

[As a consequence of section 2.4.1.11, the division of classes into one Feature_clause or more, and the labels of these clauses, appear in this document for the sole purpose of readability and ease of opdreference, but are not part of this Standard.]

[The goal pursued by the preceding definition is to make sure that an Eiffel system that follows this Standard will be correctly processed by any compatible implementation, without limiting the implementors' freedom to provide more ambitious facilities.]