Previous | Table of Contents | Next |
When sent to a block, the message ensure: causes the receiver to be evaluated just as if the message value had been sent to the block. The value returned is the result of evaluating the receiver. The argument to the ensure: method is a block called the clean-up block. After evaluating the receiver, the clean-up block is also evaluated. The clean-up block is also automatically evaluated if for any reason the receiver block does not return normally. In particular, if an exception occurs while evaluating the receiver, the clean-up block is executed if the exception handler does not resume execution within the receiver block. Executing an explicit return that goes outside the receiver block is another situation that causes execution of the clean-up block. This is illustrated by the following example:
myFile whileLockedDo: [myFile atEnd ifTrue: [^nil] ifFalse: [myFile next]]
The clean-up block within whileLockedDo: is executed even if the argument block encounters an end of file and explicitly returns nil.
The message ifCurtailed: is similar to ensure:. Its receiver is a block and its argument is a clean-up block. The message ifCurtailed: differs in that its clean-up block is evaluated only if the receiver block does not complete normally.
We have now covered most of the essential features of the Smalltalk programming language. The language is quite simple and primarily provides a means for defining new classes of objects and for orchestrating message interaction between objects.
All Smalltalk systems include a large library of predefined classes. Familiarity with and use of these classes is a key part of successful Smalltalk programming. A Smalltalk program never starts out as a blank sheet of paper that the programmer fills with newly written classes. Instead, Smalltalk programmers start with the predefined class library and choose which of the classes can be reused to implement the current programming task.
Modern commercial Smalltalk development environments provide more than a thousand classes in their class libraries. Such libraries provide classes that support all aspects of modern applications, including graphical user interfaces, relational database access, and distributed computing. The standard Smalltalk class library consists of a subset of the classes found in such libraries. The class library of standard Smalltalk is focused on classes that have nearly universal applicability. This class library provides classes that are likely to be useful for all types of applications operating in any computing environment. In addition to the basic behavior for all objects, the areas of functionality addressed by the standard library include numeric computations, string manipulation, data collections and structures, and basic file I/O.
Smalltalk programmers generally do not need to be aware of the implementation details of a class in order to use it. Instead, Smalltalk programmers must understand the public behavior of a classs instances. We have seen how, through the use of polymorphism, different classes of objects can support identical behaviors. For these reasons, the standard Smalltalk class library is not defined as a strict implementation hierarchy of concrete classes. Instead, the standard Smalltalk class library is defined by sets of protocols. Informally, a protocol is a set of related messages that an object can support. Through the use of polymorphism, a particular protocol can be supported by many different classes, including classes that are not related through inheritance.
The definition of standard Smalltalk includes a notation for describing protocols. However, protocols are not a formal part of the Smalltalk programming language. Protocol specification can only occur embedded within comments in the text of a Smalltalk program.
A protocol is a named specification for a group of messages. A protocol specifies for each of its message selectors the function performed by the message. It also specifies what types of objects are allowed as arguments for each message and what type of object is returned as the result of the message. The types of argument and result objects are specified using protocol names and indicate that the argument or result must be an object that supports the named protocol.
The name of a protocol is one or more Smalltalk identifiers surrounded by angle brackets. Some valid protocol names include the following:
<Object> <collection class> <exceptionSignaler>
The individual messages in a protocol are each described by their signature. The signature of a message specifies a protocol that must be supported by each argument object and a protocol that is supported by the object returned by the message. The syntax of a signature specification is similar to the message pattern of a method. However, instead of argument names, a signature specifies the protocol name for each argument. A signature specifies the result type of a message with a return symbol (^) followed by the protocol name of the object returned by the message. Here are some signatures:
negated ^ <number> & <boolean> ^ <boolean> detect: <object> ifNone: <block0> ^ <object>
Some messages are used exclusively for their side effects. The result object is usually ignored for such messages and is excluded from its signature.
A protocol specification can also specify the names of one or more protocols to which the specified protocol is said to conform. Protocol conformance is essentially inheritance of signatures. If protocol <a> conforms to protocol <b>, then all message signatures of <b> are implicitly also part of protocol <a>. In addition, protocol <a> can refine the argument and result types and the semantic specification of any message signature from <b>.
As an introduction to the standard Smalltalk class library, the following section describes some of its most important protocols. These include the protocols that all objects support and the protocols for the most commonly used objects, such as numbers and boolean values. The following section also describes the principal protocols for collections, which are the objects most commonly used to create data structures. Some of the protocols that are not described include streams, which are used primarily for file access, and the protocols for objects representing dates and times. The descriptions of the protocols follow the terminology and structure developed for standard Smalltalk by the X3J20 committee. In a few cases, the protocols have been slightly simplified or abridged.
Previous | Table of Contents | Next |