Previous | Table of Contents | Next |
Because of the call to some_feature, the routine does not work unless its precondition is satisfied. A call a.r (x) can appear as if x /= Void then a.r (x) end, but this is not the only possible scheme; for example, if the preceding instruction is !! x, then we know x is not void and do not need to protect the call at all. In some cases, however, the argument showing that x is not void might be less obvious; for example, x could have been obtained, in a non-adjacent part of the algorithm, as clone (y) for some y that we know is not void. It is good practice in this case to write the call as
check x_not_void: x /= Void end -- Because x was obtained as a clone of y, and y is not void because [etc.] end a.r (x)
Note the recommended convention: extra indentation of the check part to separate it from the algorithm proper, and inclusion of a comment listing the rationale behind the developers decision not to check explicitly for the precondition.
In production mode with assertion monitoring turned off, this instruction has no effect. But it is precious for a maintainer of the software who is trying to figure out what it does and in the process to reconstruct the original developers reasoning. (The maintainer might of course be the same person as the developer, six months later.) If the rationale is wrong somewhere, turning on assertion checking immediately uncovers the bug.
Eiffel software texts are free-format: Distribution into lines is not semantically significant, and any number of successive space and line-return characters is equivalent to just one space. The style rules suggest indenting software texts as illustrated by the examples in this chapter.
About 65 namesall unabbreviated single English words, except for elseif, which is made of two wordsare reserved, meaning that they cannot be used to declare new entities.
Most of them are keywords, serving only as syntactic markers, and conventionally written in boldface in texts such as the present one: class, feature, inherit, and so on. Other reserved words, such as Current, directly carry a semantic denotation.
Except in manifest character constants (appearing in single quotes, such as A) and character strings (appearing in double quotes, such as lower and UPPER), letter case is not significant, to avoid errors due to subtle differences in writing an identifier. The style rules are again quite strict: They suggest writing class names in uppercase, as ACCOUNT, non-constant feature names and keywords in lowercase, as balance and class, and constant features and predefined entities and expressions with an initial lowercase, as Avogadro and Current.
Successive declarations or instructions may be separated by semicolons. Eiffels syntax has been so designed, however, that (except in rare cases) the semicolon is optional. Omitting semicolons for elements appearing on separate lines lightens text and is the recommended practice. For clarity, however, successive elements appearing on a single line should always be separated by semicolons. These are the rules applied in this chapter.
Recent work has resulted in advanced mechanisms being made available to the Eiffel community in the area of concurrency, Internet development, multithreading, and CORBA.
Many proposals have been made to make Eiffel support concurrent programming; an extensive bibliography may be found at http://www.eiffel.com. The most developed of these proposals in the process of being submitted t‹o the NICE Eiffel consortium at the time of this writing is known as SCOOPsimple concurrent object-oriented programmingand is the result owork performed between 1991 and 1996.
The key word in SCOOP is the first: simple. SCOOP represents a minimal extension to Eiffelone keyword, separateand takes full advantage of the existing sequential Eiffel mechanisms, remaining fully compatible with the spirit of the method that it prolongs to its natural concurrent counterparts. In spite of its simplicity, it is extremely general, covering all known forms of concurrency, from multiple processes to Internet programming, multithreading, and distributed computation (all implemented or being implemented in ISEs environment at the time of writing). The following summary is drawn from the chapter on concurrency in Object-Oriented Software Construction (Meyer, 1997).
We use the fundamental scheme of OO computation: feature call, x.f (a), executed on behalf of some object O1 and calling f on the object O2 attached to x, with the argument a. Instead of a single processor that handles operations on all objects, we may now rely on different processors for O1 and O2so that the computation on O1 can move ahead without waiting for the call to terminate because another processor handles it.
Because the effect of a call now depends on whether the objects are handled by the same processor or different ones, the software text must tell us unambiguously what the intent is for any x. Hence the need for the single new keywordrather than just x: SOME_TYPE, we declare x: separate SOME_TYPE to indicate that x is handled by a different processor so that calls of target x can proceed in parallel with the rest of the computation. With such a declaration, any creation instruction !! x.make (...) spawns a new processora new thread of controlto handle future calls on x.
Previous | Table of Contents | Next |