The Eiffel Library Kernel Standard, 2001 Vintage

Adopted by the NICE Board in August 2001.
Ratified by the members of NICE in August 2001.

The class text at the end of this document replaces the existing STRING class in the ELKS 2000 specification to yield the Eiffel Library Kernel Standard, 2001 Vintage (ELKS 2001).

The explanatory notes at the front of this document are not part of the official standard.

This page is also available in Hindi (translated by James Galea).

The Design Process

Although this proposal builds on earlier work, this version is the result of intensive discussions over the last two years on the eiffel-nice-libraries email list.

Every part of the STRING class has been considered in detail, with respect to the following goals:

1. To maximise interoperability between the different implementations of Eiffel.
2. To minimise the impact on existing code.
3. To minimise the work required by vendors to support the updated standard.

It was most definitely not a goal to achieve the best possible design. We all knew better ways to do things, if we were starting with a blank slate. But we realised that a significant improvement in interoperability now would be much better than a "perfect" design that may never be implemented.

The discussions have been both extensive and intensive. We have looked in detail at every feature of the class. This is by far the largest of the ELKS classes, and current implementations have many incompatibilities. This has contributed to the length of time taken to produce this proposal.

Participants in the discussions included library authors, end users, and representatives of all Eiffel vendors. We are all very excited by the possibility to achieve a truly interoperable kernel library for Eiffel.

About The Specification

We have aimed to fully-specify the ELKS 2001 STRING class. In most cases the specification is by means of Eiffel assertions, although we used free-form text and BNF productions in a few places where a specification using assertions would have been cumbersome or impractical.

The feature postconditions are precise but sometimes lengthy, as they use recursion to assert a condition over all elements of the STRING.

Please note the following points:

• A vendor is not required to include these assertions in the delivery of a conforming kernel library.
• The complex postconditions may be rather daunting to the novice, and we anticipate that versions of the standard will be circulated in other formats too.

Two of the features are grouped together under the tag "Basic specifiers", and have no postconditions. All other queries are specified (directly or indirectly) in terms of these two queries. All commands are specified by their effect on the values of these two queries. This approach is due to James McKim, and was pioneered successfully in the ELKS 2000 ARRAY specification.

Changes From ELKS 1995 to ELKS 2000

ELKS 2001 STRING Class

Copyright Notice

Copyright © 2001 NICE. Eiffel and NICE are trademarks of the Nonprofit International Consortium for Eiffel.

Copyright © 2001-2019, Nonprofit International Consortium for Eiffel Last Updated: 14 April 2019