Changes From ELKS 1995 to ELKS 2000 PreviousNext

Three of the areas of change are wide-ranging, and deserve special mention:

Summary Of All Changes

Add creation features make_empty and make_filled. Refine the specification of make.

The new creation features provide for migration of existing code that uses non-standard implementations of make having "count" semantics.

We expect these new creation features to be generally useful for other code too.

The specification of make remains consistent with the "capacity" semantics described in ETL and OOSC.

Inconsistency in implementations of make has been a major hindrance to interoperability in the past. We anticipate that ELKS 2001 STRING will enable interoperability to be achieved.

Remove feature remake and export make to {ANY}.

Feature remake was not interoperable.

Vendors may retain their existing implementations outside of the ELKS standard.

Feature make may now be used for creation and for reinitialization.

Remove feature resize.

Feature resize was not interoperable. In some implementations it changed count and in others it changed capacity.

The functionality provided by resize can be provided by other ELKS features, although perhaps not so conveniently.

Vendors may retain their existing incompatible implementations of resize outside of the ELKS standard.

Rename feature fill to fill_with.

Feature fill was not interoperable, as it changed count in some implementations but not others. It was decided to introduce a new rigorously-specified feature fill_with that does not change count.

Rename feature insert to insert_string. Refine the specifications of features insert_string and insert_character.

Feature insert was inserting a STRING in some implementations and a CHARACTER in others.

The rigorously-specified features insert_character and insert_string now provide a sound basis for interoperability.

Remove features left_adjust, right_adjust, append_boolean, append_real, append_double, append_integer.

These features are only partially interoperable in current implementations. It was considered more practical to remove the features from the standard than to achieve convergence.

The functionality offered by these features can easily be provided outside the kernel.

Features removed from the standard may still be supported by a conforming implementation, and could be re-introduced into a future version of the standard if the interoperability problems can be overcome.

Add features has and infix "+".

We considered these features to be very useful. They are already implemented outside of ELKS by all vendors. These features are also particularly useful in the specification itself.

Add feature has_substring.

We considered this feature to be very useful. It is already implemented outside of ELKS by some vendors. This feature is also particularly useful in the specification itself.

Refine the specifications of substring, substring_index.

These features did not handle empty strings in some implementations. In some cases the feature preconditions made it impossible to work with empty strings; in other cases incorrect results were generated.

These features now handle empty strings consistently and seamlessly. Without that change it would have been difficult to specify this class rigorously, as these features are used in the ELKS 2001 STRING assertions.

Consistent handling of empty strings has also been provided throughout the rest of the STRING class.

Refine the specifications of occurrences, count, valid_index, item, infix "@", put, is_equal, copy, is_empty, hash_code, out, remove, append_string, append_character, to_integer, to_boolean, to_real, to_double, index_of, infix "<=", infix ">", infix ">=", is_lower, is_upper, from_c, wipe_out, make_from_string and the class invariant.

These specifications were refined to make them rigorous. Sometimes the specification matches what is already implemented by all vendors. Other times, minor changes will be needed by one or more vendors. However, we do not expect significant disruption to existing code.

Add features is_integer, is_boolean, is_real, is_double.

These features were added to enable us to rigorously specify the preconditions of to_integer, to_boolean, to_real and to_double. We also consider them to be generally-useful features.

Add features as_lower, as_upper.

These new queries were added to enable us to rigorously specify the postconditions of the commands to_lower and to_upper.

Add features string and same_string.

These new features work with the character sequence of a STRING or STRING-like object. Because they refer only to the character sequence, even in proper descendants, they enabled us to write specifications for features such as `make_from_string' that are rigorous in STRING and in any descendant.

Replace features head and tail by keep_head, keep_tail, remove_head, remove_tail and remove_substring.

The revised feature names are considered to be more clear and consistent.

The feature names head and tail were considered to suggest queries, not commands.

Rename feature put_substring to replace_substring.

Neither of these features is supported by all current implementations. replace_substring was considered to be the better name.

Refine the specification of infix "<".

The new specification of infix "<" makes it clear that comparison is to be based on the character codes of the STRING elements.

The specifications of the features of class COMPARABLE, and of feature infix "<" of class CHARACTER, will need to be tweaked to make string comparison completely rigorous.

Rename feature empty to is_empty.

This change was made for naming consistency.

It is not possible in this short presentation to effectively summarise the discussions that led to these changes. If you want to know why these changes were considered appropriate, please browse the archive of the discussions at http://groups.yahoo.com/group/eiffel-nice-library.

We took a consensus poll for every one of these changes. The majority of changes gained near-unanimous or unanimous support, although a sprinkling of more minor ones were contentious.

Future Work

Some areas that have been identified for possible future work are:


Copyright 2001, Nonprofit International Consortium for Eiffel
Last Updated: 28 December 2001

HomeTocPreviousNext