ET: Other Mechanisms

We now examine a few important mechanisms that complement the preceding picture.

Manifest constants

Sometimes we want to provide in software text a self-denoting value of a particular type. In Eiffel this is what we call a manifest constant. For example, if we are searching an indexed structure, we might have an integer variable that we would want to initialize to reference the first item in the structure:

my_index := 1

In this case we used a manifest constant, 1, to provide an initial value for my_index. In particular, this is a manifest integer.

Eiffel also supports manifest constants for real (and double) numbers (ex: 3.1415), boolean values (ex: True, False), and characters (ex: 'A', with special characters expressed using a percent sign as in '%N' for new line, '%B' for backspace, '%"' for double quote, and '%U' for null).

Manifest constants are also available for strings, using double quotes as in: "Hello world!". As with character constants, special characters are denoted using the % codes.

Verbatim strings

You may occasionally have a need for a manifest string that represents a multi-line formatted string. In Eiffel we call this type of manifest string a verbatim string, and there is a special syntax for specifying verbatim strings in Eiffel code. Verbatim strings are either aligned or non-aligned. Aligned verbatim strings will automatically be adjusted so that their leftmost line (the line with text characters closest to the left margin) contains no "white space" to the left of the first text character. For non-aligned verbatim strings, the white space is left untouched. You use a slightly different way of specifying each type of string. For example, this aligned verbatim string:

my_aligned_string: STRING = "[ Thrice hail the still unconquered King of Song! For all adore and love the Master Art That reareth his throne in temple of the heart; And smiteth chords of passion full and strong Till music sweet allures the sorrowing throng! ]"

will print like this:

Thrice hail the still unconquered King of Song! For all adore and love the Master Art That reareth his throne in temple of the heart; And smiteth chords of passion full and strong Till music sweet allures the sorrowing throng!

The same string, declared as a non-aligned verbatim string:

my_non_aligned_string: STRING = "{ Thrice hail the still unconquered King of Song! For all adore and love the Master Art That reareth his throne in temple of the heart; And smiteth chords of passion full and strong Till music sweet allures the sorrowing throng! }"

will print like this:

Thrice hail the still unconquered King of Song! For all adore and love the Master Art That reareth his throne in temple of the heart; And smiteth chords of passion full and strong Till music sweet allures the sorrowing throng!

The difference in declaration is that the aligned verbatim string uses as its "opener" the double-quote plus bracket combination, " "[ ", and the bracket plus double quote, " ]" ", as its "closer". The non-aligned verbatim string uses braces, " { " and " } " instead of the bracket.

The syntax for specifying verbatim strings allows an option for the situation in which the specified string might conflict with the "closer". You can include a simple string between the double quote and the bracket on each end of the verbatim string to guarantee uniqueness. Here's our aligned verbatim string with the simple string " *? " inserted in the opener and closer:

my_aligned_string: STRING = "*?[ Thrice hail the still unconquered King of Song! For all adore and love the Master Art That reareth his throne in temple of the heart; And smiteth chords of passion full and strong Till music sweet allures the sorrowing throng! ]*?"

Constant attributes

The attributes studied earlier were variable: each represents a field present in each instance of the class and changeable by its routines.

It is also possible to declare constant attributes, as in Solar_system_planet_count: INTEGER = 8

These will have the same value for every instance and hence do not need to occupy any space in objects at execution time. (In other approaches similar needs would be addressed by symbolic constants, as in Pascal or Ada, or macros, as in C.)

What comes after the = is a manifest constant. So you can declare a constant attribute for any type for which there is a manifest constant.

Obsolete features and classes

One of the conditions for producing truly great reusable software is to recognize that although you should try to get everything right the first time around you won't always succeed. But if "good enough" may be good enough for application software, it's not good enough, in the long term, for reusable software. The aim is to get ever closer to the asymptote of perfection. If you find a better way, you must implement it. The activity of generalization, discussed as part of the lifecycle, doesn't stop at the first release of a reusable library.

This raises the issue of backward compatibility: how to move forward with a better design, without compromising existing applications that used the previous version?

The notion of obsolete class and feature helps address this issue. By declaring a feature as obsolete, using the syntax enter (i: INTEGER; x: G) obsolete "Use ` put (x, i)' instead " require ... do put (x, i) end

you state that you are now advising against using it, and suggest a replacement through the message that follows the keyword obsolete, a mere string. The obsolete feature is still there, however; using it will cause no other harm than a warning message when someone compiles a system that includes a call to it. Indeed, you don't want to hold a gun to your client authors' forehead ("Upgrade now or die !"); but you do want to let them know that there is a new version and that they should upgrade at their leisure.

Besides routines, you may also mark classes as obsolete.

The example above is a historical one, involving an early change of interface for the EiffelBase library class ARRAY; the change affected both the feature's name, with a new name ensuring better consistency with other classes, and the order of arguments, again for consistency. It shows the recommended style for using obsolete:

• In the message following the keyword, explain the recommended replacement. This message will be part of the warning produced by the compiler for a system that includes the obsolete element.
• In the body of the routine, it is usually appropriate, as here, to replace the original implementation by a call to the new version. This may imply a small performance overhead, but simplifies maintenance and avoids errors.

It is good discipline not to let obsolete elements linger around for too long. The next major new release, after a suitable grace period, should remove them.

The design flexibility afforded by the obsolete keyword is critical to ensure the harmonious long-term development of ambitious reusable software.

Creation variants

The basic forms of creation instruction, and the one most commonly used, are the two illustrated earlier ( "Creating and initializing objects" ): create x.make (2000) create x

the first one if the corresponding class has a create clause, the second one if not. In either form you may include a type name in braces, as in create {SAVINGS_ACCOUNT} x.make (2000)

which is valid only if the type listed, here SAVINGS_ACCOUNT, conforms to the type of x, assumed here to be ACCOUNT. This avoids introducing a local entity, as in local xs: SAVINGS_ACCOUNT do create xs.make (2000) x := xs ...

and has exactly the same effect. Another variant is the creation expression, which always lists the type, but returns a value instead of being an instruction. It is useful in the following context: some_routine (create {ACCOUNT}.make (2000))

which you may again view as an abbreviation for a more verbose form that would need a local entity, using a creation instruction: local x: ACCOUNT do create x.make (2000) some_routine (x) ...

Unlike creation instructions, creation expressions must always list the type explicitly, {ACCOUNT} in the example. They are useful in the case shown: creating an object that only serves as an argument to be passed to a routine. If you need to retain access to the object through an entity, the instruction create x ... is the appropriate construct.

The creation mechanism gets an extra degree of flexibility through the notion of default_create. The simplest form of creation instruction, create x without an explicit creation procedure, is actually an abbreviation for create x.default_create, where default_create is a procedure defined in class ANY to do nothing. By redefining default_create in one of your classes, you can ensure that create x will take care of non-default initialization (and ensure the invariant if needed). When a class has no create clause, it's considered to have one that lists only default_create. If you want to allow create x as well as the use of some explicit creation procedures, simply list default_create along with these procedures in the create clause. To disallow creation altogether, include an empty create clause, although this technique is seldom needed since most non-creatable classes are deferred, and one can't instantiate a deferred class.

One final twist is the mechanism for creating instances of formal generic parameters. For x of type G in a class C [G], it wouldn't be safe to allow create x, since G stands for many possible types, all of which may have their own creation procedures. To allow such creation instructions, we rely on constrained genericity. You may declare a class as [G -> T create cp end]

to make G constrained by T, as we learned before, and specify that any actual generic parameter must have cp among its creation procedures. Then it's permitted to use create x.cp, with arguments if required by cp, since it is guaranteed to be safe. The mechanism is very general since you may use ANY for T and default_create for cp. The only requirement on cp is that it must be a procedure of T, not necessarily a creation procedure; this permits using the mechanism even if T is deferred, a common occurrence. It's only descendants of T that must make cp a creation procedure, by listing it in the create clause, if they want to serve as actual generic parameters for C.

Non-object calls

The Eiffel model for object-oriented computation involves the application of some feature f to some object x, and possibly passing arguments a:

x.f (a)

This type of feature call is known as an object call because it applies the feature to a target object, in this case x. However, under certain circumstances we may apply a feature of a class in a fashion that does not involve a target object. This type of call is a non-object call. In place of the target object, the syntax of the non-object call uses the type on which the feature can be found.

circumference := radius * 2.0 * {MATH_CONST}.pi

In the sample above, the call to feature {MATH_CONST}.Pi is a non-object call. This case illustrates one of the primary uses of non-object calls: constants. The library class MATH_CONST contains commonly used mathematical constants. Non-object calls make it possible to use the constants in MATH_CONST without having to create an instance of MATH_CONST or inherit from it.

The other primary use is for external features. One example is when we use Microsoft .NET classes from Eiffel code and have to access mechanisms for which there is no direct analog in Eiffel. Microsoft .NET supports so-called "static" methods and enumeration types. To access these, we use non-object calls. In the example below, a non-object call is used to access the enumeration CreateNew from the .NET enumeration type System.IO.FileMode.

create my_file_stream.make ("my_file.txt", {FILE_MODE}.create_new)

The validity of a non-object call is restricted in ways that mirror these primary uses. That is, any feature called in a non-object call must be either a constant attribute, an external feature, or a class feature. (See the ISO/ECMA Eiffel standard document for additional details.)

Class feature

A feature with a class postcondition is known as a class feature and can be used in non-object calls. A class postcondition consists of a single keyword class (with an optional leading tag):

disc_area (radius: REAL_32): REAL_32 -- Area of a disk of radius `radius`. do Result := radius * radius * {MATH_CONST}.pi ensure instance_free: class end

A class feature can be used not only in object calls, but also in non-object calls. For example, assuming the feature above is defined in class GEOMETRY, it can be called without creating an object:

area := {GEOMETRY}.disc_area (r)

A class feature is valid only when it does not

• access Current;
• access a variable attribute;
• declare an unqualified agent;
• make an unqualified call to a non-class feature.

Although an external feature without assertions can be used in non-object calls, it is a good practice to add a class postcondition if such usage is expected. This guarantees that no added or inherited assertion violates the validity rule for a class feature.

Convertibility

It is useful at times to designate that instances of one type can be created through the controlled conversion of instances of some other type. This can be done through a safe Eiffel type conversion mechanism called convertibility.

Convertibility is useful when refactoring, moving from one design to another, or, as you will see in the example, accommodating external technologies over which we have no control.

Definition -- Convertibility: converts to, converts from:

A type U based on a class CU converts to a type T based on a class CT (and T converts from U) if either

CT has a conversion procedure using U as a conversion type, or

CU has a conversion query listing T as a conversion type,

but not both.

Before we get into an example of convertibility, let's list some of its underlying principles:

1. Conversion Principle: No type may both conform and convert to another.
2. Conversion Asymmetry Principle: No type may convert to another through both a conversion procedure and a conversion query.
3. Conversion Non-transitivity Principle: That V converts to U and U converts to T does not imply that V converts to T.

Let's look at an example with which you may already be familiar.

my_string: STRING_8 -- Native Eiffel string my_system_string: SYSTEM_STRING -- Native Microsoft .Net string … my_string := my_system_string

In the snippet above, we have attributes declared of type STRING_8 and SYSTEM_STRING.

We know that if we have a attribute of type STRING_8 that we can make a direct assignment of a .Net type of string (that is, the .Net type System.String which we see as class SYSTEM_STRING) to our STRING_8 attribute.

We know also that SYSTEM_STRING does not conform to STRING_8, so according to the definition of compatibility, this must happen through conversion.

Therefore SYSTEM_STRING converts to STRING_8. And according to the definition above this means that either:

1. Class SYSTEM_STRING has a conversion query listing STRING_8 as a conversion type, or
2. Class STRING_8 has a conversion procedure listing SYSTEM_STRING as a conversion type

In this case STRING_8 has a conversion procedure for objects of type SYSTEM_STRING. Conversion procedures are always creation procedures. So they appear in both the create and the convert parts of the class.

class STRING_8 … create make_from_cil … convert make_from_cil ({SYSTEM_STRING}) …

We won't show the implementation of the conversion procedure, but as you can imagine, it initializes its target with the content of its argument.

Because of convertibility, this code:

my_string := my_system_string

is equivalent to:

create my_string.make_from_cil (my_system_string)

So, we've seen how SYSTEM_STRING converts to STRING_8. But, in the context of our example, we could also do this:

my_system_string := my_string

Which means that STRING_8 converts to SYSTEM_STRING. The convert part of class STRING_8 also has a conversion query listing SYSTEM_STRING as a conversion type:

class STRING_8 … create make_from_cil … convert make_from_cil ({SYSTEM_STRING}) to_cil: {SYSTEM_STRING} …

Because of convertibility, this code:

my_system_string := my_string

is equivalent to:

my_system_string := my_string.to_cil

You should bear in mind that assignments are not the only situation in which conversions take place. Convertibility works for other types of attachments as well. For example, if a routine calls for an argument of type SYSTEM_STRING, and you supply an actual argument of type STRING_8, this constitutes an attachment, and the conversion from STRING to SYSTEM_STRING will occur.

Tuple types

The study of genericity described arrays. Another common kind of container objects bears some resemblance to arrays: sequences, or "tuples", of elements of specified types. The difference is that all elements of an array were of the same type, or a conforming one, whereas for tuples you will specify the types we want for each relevant element. A typical tuple type is of the form TUPLE [X, Y, Z]

denoting a tuple of at least three elements, such that the type of the first conforms to X, the second to Y, and the third to Z.

You may list any number of types in brackets, including none at all: TUPLE, with no types in brackets, denotes tuples of arbitrary length.

Info: The syntax, with brackets, is intentionally reminiscent of generic classes, but TUPLE is a reserved word, not the name of a class; making it a class would not work since a generic class has a fixed number of generic parameters. You may indeed use TUPLE to obtain the effect of a generic class with a variable number of parameters.

To write the tuples themselves -- the sequences of elements, instances of a tuple type -- you will also use square brackets; for example [x1, y1, z1]

with x1 of type X and so on is a tuple of type TUPLE [X, Y, Z].

The definition of tuple types states that TUPLE [X1 ... Xn] denotes sequences of at least n elements, of which the first n have types respectively conforming to X1, ..., Xn. Such a sequence may have more than n elements.

Features available on tuple types include count: INTEGER, yielding the number of elements in a tuple, item (i: INTEGER): ANY which returns the i-th element, and put which replaces an element.

Tuples are appropriate when these are the only operations you need, that is to say, you are using sequences with no further structure or properties. Tuples give you "anonymous classes" with predefined features count, item and put. A typical example is a general-purpose output procedure that takes an arbitrary sequence of values, of arbitrary types, and prints them. It may simply take an argument of type TUPLE, so that clients can call it under the form write ([your_integer, your_real, your_account])

As soon as you need a type with more specific features, you should define a class.