Table of Contents Previous Chapter

0 INTRODUCTION

[This introduction is not part of the Standard.]

0.1

To favor the interoperability between implementations of Eiffel, it is necessary, along with a precise definition of the language, to have a well-defined set of libraries covering needs that are likely to arise in most applications. This library is known in Eiffel as the Kernel Library.

0.2

The present document defines a standard for the Kernel Library. If an Eiffel implementation satisfies this Standard --- under the precise definition of Kernel Compatibility given in section 2.2 --- it will be able to handle properly any Eiffel system whose use of the Kernel Library only assumes the library properties defined in this Standard.

0.3

The Eiffel Library standardization process, as described in Appendix A of the present document, is based on a dynamic view which, in the spirit of Eiffel's own "feature obsolescence" mechanism, recognizes the need to support evolution while preserving the technology investment of Eiffel users. One of the consequences of this dynamic view is to define vintages corresponding to successive improvements of the Standard. The present document describes Vintage 95, valid for the calendar year 1995.

The Eiffel Kernel Library Kernel Standard, denoted in the present document by the phrase "this Standard", is made up of the contents of sections 1 to 5 of the present document, with the exception of elements appearing between square brackets [...] which are comments.

[As a result of the preceding definition the following elements are not part of this Standard: section 0, the table of contents, Appendix A in section 6 (the Kernel Library Standardization process), Appendix B in section 7 (list of differences), the Index (currently removed from the Web version), and elements playing a pure typesetting role such as page headers.]

1.2 Scope of this Standard

This Standard defines a number of library-related conditions that an Eiffel implementation must satisfy. These conditions affect a set of classes known as the kernel library. An implementation that satisfies the conditions described in this Standard will be said to be kernel-compatible, a phrase that is abbreviated in this Standard as just "compatible".

[In other contexts it may be preferable to use the full phrase, since the compatibility of an Eiffel implementation also involves other aspects, such as language compatibility.]

[The terms "compatibility" and "compatible" may be felt to be less clear than "conformance" and "conformant". The former are used here, however, since talking about conformance might cause confusions with the Eiffel notion of a type conforming to another.]

1.3 Other documents

The phrase Eiffel: The Language as used in this Standard refers to the second printing of the book Eiffel: The Language, Prentice Hall, 1992, ISBN 0-13-245-925-7.

For the purposes of this Standard, the definition of the Eiffel language is the definition given by Eiffel: The Language.

In case of contradictions between the library specifications given by Eiffel: The Language and those given in this Standard, the latter shall take precedence.

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, given on page 10.]

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:

1. For each of the Required Classes, the implementation includes a class with the same name.
   

2. All the Required Ancestry Links are present between these classes.
   

3. The flatshort form of each one of these classes is Flatshort-Compatible with the corresponding Required Flatshort Form.
   

4. All the dependents of the Required Classes in the implementation are also included in the implementation.
   

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:

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. The Creation clause of the flatshort specification shall include the full specification of all general creation procedures of C.
   

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

1. A feature f from GENERAL shall be included if and only if C redeclares f.
   

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

1. 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.]

1. If deferred, C shall appear as deferred class.
   

2. Any deferred feature of C shall be marked as deferred.
   

3. In case of precondition redeclaration, the successive preconditions shall appear as a single Precondition clause, separated by semicolons.
   

4. 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:

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

1. An invariant clause that appears in ic but not in sc.
   

2. For a feature that appears in both ic and sc, a postcondition clause that appears in ic but not in sc.
   

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

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

5. A difference between the Tag_mark of an Assertion_clause in ic and its counterpart in sc.
   

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

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

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

9. An Index_clause that appears in ic but not in sc.
   

10. 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.]

3 REQUIRED CLASSES

The Required Classes are the following twenty-six classes [ordered from the general to the specific, as in section 5]:

1. GENERAL [flatshort form in section 5.1].
   

2. ANY [flatshort form in section 5.2].
   

3. COMPARABLE [flatshort form in section 5.3].
   

4. HASHABLE [flatshort form in section 5.4].
   

5. NUMERIC [flatshort form in section 5.5].
   

6. BOOLEAN [flatshort form in section 5.6].
   

7. CHARACTER [flatshort form in section 5.7].
   

8. INTEGER [flatshort form in section 5.8].
   

9. REAL [flatshort form in section 5.9].
   

10. DOUBLE [flatshort form in section 5.10].
    

11. POINTER [flatshort form in section 5.11].
    

12. ARRAY [flatshort form in section 5.12].
    

13. STRING [flatshort form in section5.13).
    

14. STD_FILES [flatshort form in section 5.14].
    

15. FILE [flatshort form in section 5.15].
    

16. STORABLE [flatshort form in section 5.16].
    

17. MEMORY [flatshort form in section 5.17].
    

18. EXCEPTIONS [flatshort form in section 5.18].
    

19. ARGUMENTS [flatshort form in section 5.19].
    

20. PLATFORM [flatshort form in section 5.20].
    

21. BOOLEAN_REF [flatshort form in section 5.21].
    

22. CHARACTER_REF [flatshort form in section 5.22].
    

23. DOUBLE_REF [flatshort form in section 5.23].
    

24. INTEGER_REF [flatshort form in section 5.24].
    

25. POINTER_REF [flatshort form in section 5.25].
    

26. REAL_REF [flatshort form in section 5.26].
    

[The classes appear in this section and section and section 5 in the following order: universal classes; deferred classes for basic classes; basic classes; arrays and strings; operating system interface; auxiliary reference classes for the definition of basic classes.]

4 REQUIRED ANCESTRY LINKS

The following constitute the required ancestry links [ordered alphabetically, after the first rule, by the name of the applicable descendant class]:

1. Every Required Class except GENERAL is a descendant of ANY
   

2. ANY is an heir of GENERAL.
   

3. BOOLEAN is a proper descendant of BOOLEAN_REF.
   

4. BOOLEAN_REF is a proper descendant of HASHABLE.
   

5. CHARACTER is a proper descendant of CHARACTER_REF.
   

6. CHARACTER_REF is a proper descendant of COMPARABLE.
   

7. CHARACTER_REF is a proper descendant of HASHABLE.
   

8. DOUBLE is a proper descendant of DOUBLE_REF.
   

9. DOUBLE_REF is a proper descendant of COMPARABLE.
   

10. DOUBLE_REF is a proper descendant of HASHABLE.
    

11. DOUBLE_REF is a proper descendant of NUMERIC.
    

12. FILE is a proper descendant of MEMORY.
    

13. INTEGER is a proper descendant of INTEGER_REF.
    

14. INTEGER_REF is a proper descendant of COMPARABLE.
    

15. INTEGER_REF is a proper descendant of HASHABLE.
    

16. INTEGER_REF is a proper descendant of NUMERIC.
    

17. POINTER is a proper descendant of POINTER_REF.
    

18. POINTER_REF is a proper descendant of HASHABLE.
    

19. REAL is a proper descendant of REAL_REF.
    

20. REAL_REF is a proper descendant of COMPARABLE.
    

21. REAL_REF is a proper descendant of HASHABLE.
    

22. STRING is a proper descendant of COMPARABLE.
    

23. STRING is a proper descendant of HASHABLE.
    

24. STRING is a proper descendant of HASHABLE.
    

[4.1 follows from Eiffel: The Language; the language description is considered to be amended in such a way that PLATFORM is a class without privileges, to be inherited explicitly by classes which need access to its features.]

Table of Contents Next Chapter

© 1985-2012 Eiffel Software. All rights reserved. -- Privacy Policy