6 \x11APPENDIX A: THE KERNEL STANDARDIZATION PROCESS [This Appendix is not part of the Standard.] 6.1 Why plan a process? The Eiffel Kernel Library cannot be specified for eternity. Ideas willcome up for new classes and features; ways will be found to do thingsbetter. The evolution process must be fast enough to enable Eiffel usersto benefit from this flow of ideas and avoid technical obsolescence, but orderly enough to protect their existing investments and modes of operation. 6.2 Cycle time A revision every ten to fifteen years, as has occurred for programming language standards (Fortran, C and Ada are examples) is not appropriate for the Eiffel Kernel Library. It would foster complacency most of the time, and major upheavals when a revision is finally brought into effect. A yearly process, similar to the upgrading of wines, car models and stable software products, provides the right pace of change. 6.3 Vintages Each revision of this Standard describes a vintage of theEiffel Library Kernel Standard. The present version is vintage 1995. 6.4 Yearly schedule The following deadlines apply to year year: 6.4.1 ·\x11\x111 January: Vintage year takes effect. 6.4.2 ·\x11\x111 April: first permitted date for starting discussions on Vintage year+1 in NICE's Library Committee. (1 January to 31 March is acooling-off period.) 6.4.3 ·\x11\x111 May: first permitted date for submitting formal proposals to the Library Committee for Vintage year + 1. 6.4.4 ·\x11\x111 July: last permitted date for submitting initial proposals for Vintage year + 1. 6.4.5 ·\x11\x111 September: last permitted date for submitting final proposals (which may result from merging of several proposals) for Vintage year + 1. 6.4.6 ·\x11\x111 October: last date by which the Committee may have defined Vintage year +1. This schedule is applicable starting with vintage 96. For the present vintage (95), the first, the date of applicability is 1 July 1995. 6.5 Intermediate corrections During the time when a vintage is in effect, minor corrections may prove necessary, due for example to typographical errors in the current version of this Standard or to inconsistencies discovered by users or implementors of Eiffel. In such a case the chairman of the Library Committee of NICE may, at his discretion, submit a motion covering one or more revisions. To be approved, such motions shall require a unanimous vote of the Library Committee, with the possible exception of any member who has notified the chairman of an absence of more than one month. If approved, such a revision shall receive a revision level and shall give rise to a modified Kernel Library Standard, identified as "Vintage year Level revision_ level". The modifications shall be integrated into the following year's vintage. 6.6 Eiffel Kernel Supplier requirements Any provider of an Eiffel environment must make the following information available to any NICE member: 6.7 ·\x11\x11Vintage and revision level currently supported. 6.8 ·\x11\x11Any features not supported. (It is not permitted to have a non-supported class.) 6.9 ·\x11\x11List of classes needed by kernel classes, but not in the kernel, hereafter referred to as para-kernel classes. 6.10 ·\x11\x11Full inheritance hierarchy of kernel and para-kernel classes. 6.11 ·\x11\x11List of names of features (immediate or inherited) that appear in the provider's kernel classes but not in this Standard. 7 \x11APPENDIX B: DIFFERENCES [This Appendix is not part of the Standard.] The following differences exist between this Standard and earlierpresentations of the Kernel Library: 7.1 ·\x11\x11Addition to GENERAL of a query default which returns the default value of the type of the current object. This also addresses the need to obtain the default value for type POINTER ; for convenience, since POINTER has no manifest constant, a query default_pointer has also been included. (See page 13.) 7.2 ·\x11\x11Adaptation of the semantics of copy and equality features (equal, is_equal and their standard_ versions) so that the result is true if and only if the objects are truly identical, and in particular have the same type. This implies a language change too; the previous definition was non-symmetric so that a\x12l\x12\x12copy (b) and equal (a, b) only applied to the fields corresponding to the attributes of a's type. The earlier effect can still be achieved through function stripped, as explained next in 7.5. (See page 12.) 7.3 ·\x11\x11Addition to GENERAL of a frozen feature same_type which specifies conformance both ways. Addition of the requirement that conforms_to is frozen too. (See page 12.) 7.4 ·\x11\x11Addition of a number of assertion clauses to the features of GENERAL, in particular to specify more precisely the semantics of equality, copying, cloning and conformance. 7.5 ·\x11\x11Addition to GENERAL of a function stripped such that stripped (a) is a clone of the current object limited to the fields that apply to a's dynamic type. As a result, the old semantics of copying and equality mentioned in 7.2 may now be achieved through calls such as a\x12l\x12\x12copy (b\x12l\x12\x12stripped (a)) and equal (a, b\x12l\x12\x12stripped (a)). (See page 12.) 7.6 ·\x11\x11Addition to GENERAL of object_id and id_object to allow unique identification of objects. (See page 12.) 7.7 ·\x11\x11In class PLATFORM, removal of the assumption that Character_bits, Integer_ bits,Real_bits and Double_bits are constants. This does notintroduce any incompatibility with earlier uses except if they relied onthe specific numerical values. (See page 46.) 7.8 ·\x11\x11Removal of PLATFORM from the universal inheritance hierarchy; PLATFORM is no longer a parent of ANY and hence an ancestor of every class, and has no particular language-defined role; classes that need its facilities must name it explicitly among their proper ancestors. This is actually a language change. (See section 4, page 10.) 7.9 ·\x11\x11Addition to PLATFORM of features Maximum_integer, Minimum_integer, Maximum_ character_code and Minimum_character_code. (See page 46.) 7.10 ·\x11\x11Addition to COMPARABLE of min and max functions and of a three-way comparison function, three_way_comparison, which returns 0, -1 or 1. (See page 15.) 7.11 ·\x11\x11Addition to the arithmetic basic classes of functions abs and sign (the latter defined in terms of three_way_comparison). Addition to REAL and DOUBLE of floor, ceiling, rounded and integer_part. Addition to DOUBLE of real_part. (See page 23 and following.) 7.12 ·\x11\x11Addition of inheritance links making all basic classes (INTEGER and so on) heirs of HASHABLE, so that it is now possible to hash any object. (See section 4, page 10.) Removal of function is_hashable and the corresponding preconditions. 7.13 ·\x11\x11Addition to ARRAY of features enter and entry as redefinable synonyms to put and item (or infix "@"), the latter becoming frozen. (See page 32.) 7.14 ·\x11\x11Addition to STORABLE of a procedure independent_store which produces machine- independent representations of object structures. (See page 42.) 7.15 ·\x11\x11Addition of a few features to class FILE describing file opening and opening modes (such as read-only or read-write). In earlier presentations the corresponding class was UNIX_FILE. The new class is very similar but removes any Unix-specific aspect. (See 5.15, page 39.) 7.16 ·\x11\x11Changes of names in class STD_FILES and FILE : for consistency with the usual Eiffel naming style, underscores were added and abbrevations were expanded. In the following list (which uses the order of appearance of the features in STD_FILES), the added underscores appear as * and the added letters appear in bold italics: last*character, last*double, last*real, last*integer, last*string, put*boolean, put*character, put*double, put*integer, put_new*line, put*real, put*string, read*character, read*double, read*integer, read*line, read*real, read*stream, read*word, to_next*line. (See 5.14, page 38, and 5.15, page 39.) 7.17 ·\x11\x11Addition to EXCEPTIONS of a procedure die that terminates the execution cleanly with a given exit status, without triggering an exception. (See page 44.) 7.18 ·\x11\x11In class STRING, replacement of the adapt function by a more convenient procedure make_from_string which descendants of the class can use to initialize a string-like object from a manifest string, as in !! t\x12l\x12\x12make_from_string ("THIS STRING"), where the type of t is a descendant of STRING. (See page 34.) 7.19 ·\x11\x11Similarly, addition to ARRAY of a procedure make_from_array allowing initialization from a manifest array, as in !! a\x12l\x12\x12make_from_array (<>). 7.20 ·\x11\x11Removal from STRING of a number of features which some committee members judged too specialized: mirror, mirrored, share, shared_with, item_code, has, prepend, set, prune, prune_all. Renaming of replace_substring to put_substring. Removal of fill_blanks, replaced by fill (applying to an arbitrary character). Change of the result type of out to STRING (rather than like Current).