Smalltalk80LanguageImplementation:Chapter 14 - Revision history

Onionmixer: 오타수정

2015-07-12T09:38:35Z

오타수정

← Older revision		Revision as of 09:38, 12 July 2015
Line 120:		Line 120:

	where className mentions the class of the receiver and messageSelector is the selector of the erroneously-sent message.		where className mentions the class of the receiver and messageSelector is the selector of the erroneously-sent message.


	Note, if nil were an instance of Object, then a message sent to it in error would state		Note, if nil were an instance of Object, then a message sent to it in error would state

Line 402:		Line 404:
	===Message Handling===		===Message Handling===

	ll processing in the Smalltalk-80 system is carried out by sending messages to objects. For reasons of efficiency, instances of class Message are only created when an error occurs and the message state must be stored in an accessible structure. Most messages in the system, therefore, do not take the form of directly creating an instance of Message and transmitting it to an object.		All processing in the Smalltalk-80 system is carried out by sending messages to objects. For reasons of efficiency, instances of class Message are only created when an error occurs and the message state must be stored in an accessible structure. Most messages in the system, therefore, do not take the form of directly creating an instance of Message and transmitting it to an object.

Onionmixer: 정오표 수정

2014-05-09T09:29:37Z

정오표 수정

Onionmixer: SMALLTALK80 Chapter 14 Kernel Support 페이지 추가

2014-04-23T12:27:04Z

SMALLTALK80 Chapter 14 Kernel Support 페이지 추가

New page

;Chapter 14 Kernel Support

==Kernel Support==

<syntaxhighlight lang="text">
Object

Magnitude
Character
Date
Time

Number
Float
Fraction
Integer
LargeNegativeInteger
LargePositiveInteger
SmallInteger

LookupKey
Association

Link

Process

Collection

SequenceableCollection
LinkedList

Semaphore

ArrayedCollection
Array

Bitmap
DisplayBitmap

RunArray
String
Symbol
Text
ByteArray

Interval
OrderedCollection
SortedCollection
Bag
MappedCollection
Set
Dictionary
IdentifyDictionary

Stream
PositionableStream
ReadStream
WriteStream
ReadWriteStream
ExternalStream
FileStream

Random

File
FileDirectory
FilePage

UndefinedObject***
Boolean***
False***
True***

ProcessorScheduler
Delay
SharedQueue

Behavior
ClassDescription
Class
MetaClass

Point
Rectangle
BitBit
CharacterScanner

Pen

DisplayObject
DisplayMedium
Form
Cursor
DisplayScreen
InfiniteForm
OpaqueForm
Path
Arc
Circle
Curve
Line
LinearFit
Spline
</syntaxhighlight>

==Class UndefinedObject==

The object nil represents a value for uninitialized variables. It also represents meaningless results. It is the only instance of class UndefinedObject.

The purpose of including class UndefinedObject in the system is to handle error messages.The typical error in evaluating Smal]talk-80 expressions is that some object is sent a message it does not understand. Often this occurs because a variable is not properly initialized--in many cases, the variable name that should refer to some other object refers to nil instead. The error message is of the form

<syntaxhighlight lang="smalltalk">
className does not understand messageSelector
</syntaxhighlight>

where className mentions the class of the receiver and messageSelector is the selector of the erroneously-sent message.
Note, if nil were an instance of Object, then a message sent to it in error would state

<syntaxhighlight lang="smalltalk">
Object does not understand messageSelector
</syntaxhighlight>

which is less explicit than stating that an undefined object does not understand the message. At the price of a class description, it was possible to improve on the error message.

Tests to see if an object is nil are handled in class Object, but reimplemented in UndefinedObject. In class Object, messages isNil and notNii are implemented as

<syntaxhighlight lang="smalltalk">
isNil
↑false
notNil
↑true
</syntaxhighlight>

In class UndefinedObject, messages isNil and notNil are implemented as

<syntaxhighlight lang="smalltalk">
isNil
↑true
notNil
↑false
</syntaxhighlight>

so that no conditional test in Object is required.

==Classes Boolean, True, and False==

Protocol for logical values is provided by the class Boolean; logical values are represented by subclasses of Boolean~True and False. The subclasses add no new protocol; they reimplement many messages to have better performance than the methods in the superclass. The idea is similar to that in testing for nil in Object and UndefinedObject; true knows that it represents logical truth and false knows that it represents logical falsehood. We show the implementation of some of the controlling protocol to illustrate this idea.

The logical operations are

{| style="border: 1px solid black;"
|- style="color: white; background-color: black;"
| colspan="2" |logical operations
|- style="vertical-align:top;"
|& aBoolean||Evaluating conjunction. Answer true if both the receiver and the argument are true.
|- style="vertical-align:top;"
|| aBoolean||Evaluating disjunction. Answer true if either the receiver or the argument is true.
|- style="vertical-align:top;"
|not||Negation. Answer true if the receiver is false, answer false if the receiver is true.
|- style="vertical-align:top;"
|eqv: aBoolean||Answer true if the receiver is equivalent to the argument, aBoolean.
|- style="vertical-align:top;"
|xor: aBoolean||Exclusive OR. Answer true if the receiver is not equivalent to aBoolean.
|- style="color: black; background-color: gray;"
| colspan="2" |Boolean instance protocol
|}

These conjunction and disjunction operations are "evaluating" --this means that the argument is evaluated regardless of the value of the receiver. This is in contrast to and: and or: in which the receiver determines whether to evaluate the argument.

{| style="border: 1px solid black;"
|- style="color: white; background-color: black;"
| colspan="2" |controlling
|- style="vertical-align:top;"
|and: alternativeBlock||Nonevaluating conjunction. If the receiver is true, answer the value of the argument; otherwise, answer false without evaluating the argument.
|- style="vertical-align:top;"
|or: alternativeBlock||Nonevaluating disjunction. If the receiver is false, answer the value of the argument; otherwise, answer true without evaluating the argument.
|- style="vertical-align:top;"
|ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock||Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBtock; otherwise answer the result of evaluating falseAlternativeBlock.
|- style="vertical-align:top;"
|ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock||Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBlock; otherwise answer the result of evaluating falseAlternativeClock.
|- style="vertical-align:top;"
|ifTrue: trueAlternativeBlock||Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBlock; otherwise answer nil.
|- style="vertical-align:top;"
|ifFalse: falseAlternativeBlock||Conditional statement. If the receiver is false, answer the result of evaluating falseAlternativeBlock; otherwise answer nil.
|- style="color: black; background-color: gray;"
| colspan="2" |Boolean instance protocol
|}

The arguments to and: and or: must be blocks in order to defer evaluation. Conditional statements are provided as messages ifTrue:ifFalse:, ifFalse:ifTrue:, ifTrue:, and ifFalse:, as already specified and exemplified throughout the previous chapters. The messages are implemented in the subclasses of class Boolean so that the appropriate argument block is evaluated.

In class True, the methods are

<syntaxhighlight lang="smalltalk">
ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
↑trueAlternativeBlock value
ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock
↑trueAlternativeBlock value
ifTrue: trueAlternativeBlock
↑trueAlternativeBlock value
ifFalse: falseAlternativeBlock
↑nil
</syntaxhighlight>

In class False, the methods are

<syntaxhighlight lang="smalltalk">
ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
↑falseAlternativeBlock value
ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock
↑falseAlternativeBlock value
ifTrue: trueAlternativeBlock
↑nil
ifFalse: falseAlternativeBlock
↑falseAtternativeBlock value
</syntaxhighlight>

If x is 3, then

<syntaxhighlight lang="smalltalk">
x > 0 ifTrue: [x ← X - 1] ifFalse: [x ← x + 1]
</syntaxhighlight>

is interpreted as x > 0 evaluates to true, the sole instance of class True; the method for ifTrue:ifFalse: is found in class True, so the block [x ← x - 1] is evaluated without further testing.

In this way, the message lookup mechanism provides an effective implementation of conditional control with no additional primitive operations or circular definitions.

==Additional Protocol for Class Object==

Protocol for class Object, shared by all objects, was introduced in Chapter 6. Several categories of messages were not included in that early discussion. Most of these are part of Object's protocol to provide system support for message handling, dependence relationships, primitive message handling, and system primitives.

===Dependence Relationships Among Objects===

Information in the Smalltalk-80 system is represented by objects. The variables of objects themselves refer to objects; in this sense, objects are explicitly related or dependent on one another. Classes are related to their superclasses and metaclasses; these classes share external and internal descriptions and are thereby dependent on one another. These forms of dependency are central to the semantics of the Smalltalk-80 language. They coordinate descriptive information among objects.

An additional kind of dependency is supported in class Object. Its purpose is to coordinateactivities among different objects. Specifically, its purpose is to be able to link one object, say A, to one or more other objects, say B, so B can be informed if A changes in any way. Upon being informed when A changes and the nature of the change, B can decide to take some action such as updating its own status. The concept of changeand update,therefore, are integral to the support of this third kind of object dependence relationship.

The protocol in class Object is

{| style="border: 1px solid black;"
|- style="color: white; background-color: black;"
| colspan="2" |dependents access
|- style="vertical-align:top;"
|addDependent: anObject||Add the argument, anObject, as one of the receiver's dependents.
|- style="vertical-align:top;"
|removeDependent: anObject||Remove the argument, anObject, as one of the receiver's dependents.
|- style="vertical-align:top;"
|dependents||Answer an OrderedCollection of the objects that are dependent on the receiver, that is, the objects that should be notified if the receiver changes.
|- style="vertical-align:top;"
|release||Remove references to objects that may refer back to the receiver. This message is reimplemented by any subclass that creates references to dependents; the expression super release is included in any such reimplementation.
|- style="color: white; background-color: black;"
| colspan="2" |change and update
|- style="vertical-align:top;"
|changed||The receiver changed in some general way; inform all the dependents by sending each dependent an update: message.
|- style="vertical-align:top;"
|changed: aParameter||The receiver changed; the change is denoted by the argument, aParameter. Usually the argument is a Symbol that is part of the dependent's change protocol; the default behavior is to use the receiver itself as the argument. Inform all of the dependents.
|- style="vertical-align:top;"
|update: aParameter||An object on whom the receiver is dependent has changed. The receiver updates its status accordingly (the default behavior is to do nothing).
|- style="vertical-align:top;"
|broadcast: aSymbol||Send the argument, aSymbol, as a unary message to all of the receiver's dependents.
|- style="vertical-align:top;"
|broadcast: aSymbol with: anObject||Send the argument, aSymbol, as a keyword message with argument, anObject, to all of the receiver's dependents.
|- style="color: black; background-color: gray;"
| colspan="2" |Object instance protocol
|}

Take, as an example, the objects that model traffic lights. A typical traffic light at a street corner is an object with three lights, each a different color. Only one of these lights can be ON at a given moment. In this sense, the ON-OFF status of each of the three lights is dependent on the status of the other two. There are a number of ways to create this relationship. Suppose we create the class Light as follows.

{| style="border: 0px solid black;"
|- style="vertical-align:top;"
|class name||Light
|- style="vertical-align:top;"
|superclass||Object
|- style="vertical-align:top;"
|instance variable names||status
|- style="vertical-align:top;"
|class methods
|<syntaxhighlight lang="smalltalk">
instance creation
setOn
↑self new setOn
setOff
↑self new setOff
</syntaxhighlight>
|- style="vertical-align:top;"
|instance methods
|<syntaxhighlight lang="smalltalk">
status
turnOn
self isOff
ifTrue: [status ← true. self changed]
turnOff
self isOn
ifTrue: [status ← false]

testing
isOn
↑status
isOff
↑status not

change and update
update: aLight
aLight = = self ifFalse: [self turnOff]

private
setOn
status ← true
setOff
status ← false
</syntaxhighlight>
|}

The model is very simple. A Light is either on or off, so a status flag is kept as an instance variable; it is true if the Light is on, false if the Light is off. Whenever a Light is turned on (turnOn), it sends itself the changed message. Any other status change is not broadcast to the dependents on the assumption that a Light is turned off in reaction to turning on another Light. The default response to changed is to send all dependents the message update: self (i.e., the object that changed is the argument to the update: message). Then update: is implemented in Light to mean turn off. If the parameter is the receiver, then, of course, the update: is ignored.

The class TrafficLight is defined to set up any number of coordinated lights. The instance creation message with: takes as its argument the number of Lights to be created. Each Light is dependent on all other Lights. When the TrafficLight is demolished, the dependencies among its Lights are disconnected (the message inherited from class Object for disconnecting dependents is release; it is implemented in TrafficLight in order to broadcast the message to all Lights).

{| style="border: 0px solid black;"
|- style="vertical-align:top;"
|class name||TrafficLight
|- style="vertical-align:top;"
|superclass||Object
|- style="vertical-align:top;"
|instance variable names||lights
|- style="vertical-align:top;"
|class methods
|<syntaxhighlight lang="smalltalk">
instance creation
with: numberOfLights
↑self new lights: numberOfLights
</syntaxhighlight>
|- style="vertical-align:top;"
|instance methods
|<syntaxhighlight lang="smalltalk">
operate
turnOn: lightNumber
(lights at: lightNumber) turnOn

initialize-release
release
super release.
lights do: [ :eachLight | eachLight release].
lights ← nil

private
lights: numberOfLights
lights ← Array new: (numberOfLights max: 1).
lights at: 1 put: Light setOn.
2 to: numberOfLights do:
[ :index | lights at: index put: Light setOff].
lights do:
[ :eachLight |
lights do:
[ :dependentLight |
eachLight ~~ dependentLight
ifTrue: [eachLight addDependent: dependentLight]]]
</syntaxhighlight>
|}

The private initialization method is lights: numberOfLights. Each light is created turned off except for the first light. Then each light is connected to all the other lights (using the message addDependent:). The simulated Traffickight operates by some round robin, perhaps timed, sequencing through each light, turning it on. A simple example shown below creates the Traffickight with the first light on, and then turns on each of the other lights, one at a time. A simulation of a traffic corner might include different models for controlling the lights.

<syntaxhighlight lang="smalltalk">
trafficLight ← TrafficLight with: 3.
trafficLight turnOn: 2.
trafficLight turnOn: 3
</syntaxhighlight>

The message turnOn: to a TrafficLight sends the message turnOn to the designated Light. If the Light is currently off, then it is set on and the message changed sent. The message changed sends update: to each dependent Light; if a dependent light is on, it is turned off.

A particularly important use of this dependency protocol is to support having multiple graphical images of an object. Each image is dependent on the object in the sense that, if the object changes, the image must be informed so that it can decide whether the change affects the displayed information. The user interface to the Smalltalk-80 system makes liberal use of this support for broadcasting notices that an object has changed; this is used to coordinate the contents of a sequence of menus of possible actions that the user can take with respect to the contents of information displayed on the screen. Menus themselves can be created by linking possible actions together, in a way similar to the way we linked together the traffic lights.

===Message Handling===

ll processing in the Smalltalk-80 system is carried out by sending messages to objects. For reasons of efficiency, instances of class Message are only created when an error occurs and the message state must be stored in an accessible structure. Most messages in the system, therefore, do not take the form of directly creating an instance of Message and transmitting it to an object.

In some circumstances, it is useful to compute the message selector of a message transmission. For example, suppose that a list of possible message selectors is kept by an object and, based on a computation, one of these selectors is chosen. Suppose it is assigned as a value of a variable selector. Now we wish to transmit the message to some object, say, to receiver. We can not simply write the expression as

<syntaxhighlight lang="smalltalk">
receiver selector
</syntaxhighlight>

because this means--send the object referred to by receiver the unary message selector. We could, however, write

<syntaxhighlight lang="smalltalk">
receiver perform: selector
</syntaxhighlight>

The result is to transmit the value of the argument, selector, as the message to receiver. Protocol to support this ability to send a computed message to an object is provided in class Object. This protocol includes methods for transmitting computed keyword as well as unary messages.

{| style="border: 1px solid black;"
|- style="color: white; background-color: black;"
| colspan="2" |message handling
|- style="vertical-align:top;"
|perform: aSymbol||Send the receiver the unary message indicated by the argument, aSymbol.The argument is the selector of the message. Report an error if the number of arguments expected by the selector is not zero.
|- style="vertical-align:top;"
|perform:aSymbol with: anObject||Send the receiver the keyword message indicated by the arguments. The first argument, aSymbol, is the selector of the message. The other argument, anObject, is the argument of the message to be sent. Report an error if the number of arguments expected by the selector is not one.
|- style="vertical-align:top;"
|perform: aSymbol with: firstObject with: secondObject||Send the receiver the keyword message indicated by the arguments. The first argument, aSymbol, is the selector of the message. The other arguments, firstObject and secondObject, are the arguments of the message to be sent. Report an error if the number of arguments expected by the selector is not two.
|- style="vertical-align:top;"
|perform: aSymbol with: firstObject with: secondObject with: thirdObject||Send the receiver the keyword message indicated by the arguments. The first argument, aSymbol, is the selector of the message. The other arguments, firstObject, secondObject, and thirdObject, are the arguments of the message to be sent. Report an error if the number of arguments expected by the selector is not three.
|- style="vertical-align:top;"
|perform: selector withArguments: anArray||Send the receiver the keyword message indicated by the arguments. The argument, selector, is the selector of the message. The arguments of the message are the elements of anArray. Report an error if the number of arguments expected by the selector is not the same as the size of anArray.
|- style="color: black; background-color: gray;"
| colspan="2" |Object instance protocol
|}

One way in which this protocol can be used is as a decoder of user commands. Suppose for example that we want to model a very simple calculator in which operands precede operators. A possible implementation represents the calculator as having (1) the current result, which is also the first operand, and (2) a possibly undefined second operand. Each operator is a message selector understood by the result. Sending the message clear, once, resets the operand; sending the message clear when the operand is reset will reset the result.

{| style="border: 0px solid black;"
|- style="vertical-align:top;"
|class name||Calculator
|- style="vertical-align:top;"
|superclass||Object
|- style="vertical-align:top;"
|instance variable names||result<br>operand
|- style="vertical-align:top;"
|class methods
|<syntaxhighlight lang="smalltalk">
instance creation
new
↑super new initialize
</syntaxhighlight>
|- style="vertical-align:top;"
|instance methods
|<syntaxhighlight lang="smalltalk">
accessing
result
↑result

calculating
apply: operator
(self respondsTo: operator)
ifFalse: [self error: 'operation not understood'].
operand isNil
ifTrue: [result ← result perform: operator]
ifFalse: [result ← result perform: operator with: operand]
clear
operand isNil
ifTrue: [result ← 0]
ifFalse; [operand ← nil]
operand: aNumber
operand ← aNumber

private
initialize
result ← 0
</syntaxhighlight>
|}

An example illustrates the use of the class Calculator.

<syntaxhighlight lang="smalltalk">
hp ← Calculator new
</syntaxhighlight>

Create hp as a Calculator. The instance variables are initialized with result 0 and operand nil.

<syntaxhighlight lang="smalltalk">
hp operand: 3
</syntaxhighlight>

Imagine the user has pressed the key labeled 3 and set the operand.

<syntaxhighlight lang="smalltalk">
hp apply: #+
</syntaxhighlight>

The user selects addition. The method for apply determines that the operator is understood and that the operand is not nil; therefore, the result is set by the expression

<syntaxhighlight lang="smalltalk">
result perform: operator with: operand
</syntaxhighlight>

which is equivalent to

<syntaxhighlight lang="smalltalk">
0 + 3
</syntaxhighlight>

The methods sets result to 3; operand remains 3 so that

<syntaxhighlight lang="smalltalk">
hp apply: #+
</syntaxhighlight>

again adds 3, so the result is now 6.

<syntaxhighlight lang="smalltalk">
hp operand: 1.
hp apply: #-.
hp clear.
hp apply: #squared
</syntaxhighlight>

The result was 6, subtract 1, and compute the square; result is now 25.

===System Primitive Messages===

There are a number of messages specified in class Object whose purpose is to support the needs of the overall system implementation. They are categorized as system primitives. These are messages that provide direct access to the state of an instance and, to some extent, violate the principle that each object has sovereign control over storing values into its variables. However, this access is needed by the language interpreter. It is useful in providing class description/development utilities for the programming environment. Examples of these messages are instVarAt: anInteger and instVarAt: anInteger put: anObject which retrieve and store the values of named instance variables, respectively.

{| style="border: 1px solid black;"
|- style="color: white; background-color: black;"
| colspan="2" |system primitives
|- style="vertical-align:top;"
|become: otherObject||Swap the instance pointers of the receiver and the argument, otherObject. All variables in the entire system that pointed to the receiver will now point to the argument and vice versa. Report an error if either object is a SmallInteger.
|- style="vertical-align:top;"
|instVarAt: index||Answer a named variable in the receiver. The numbering of the variables corresponds to the order in which the named instance variables were defined.
|- style="vertical-align:top;"
|instVarAt: index put: value||Store the argument, value, into a named variable in the receiver. The number of variables corresponds to the order in which the named instance variables were defined. Answer value.
|- style="vertical-align:top;"
|nextInstance||Answer the next instance after the receiver in the enumeration of all instances of this class. Answer nil if all instances have been enumerated.
|- style="vertical-align:top;"
|numberOfPointers||Answer the number of objects to which the receiver refers.
|- style="vertical-align:top;"
|refct||Answer the number of object pointers in the system that point at the receiver. Answer O if the receiver is a SmallInteger.
|- style="color: black; background-color: gray;"
| colspan="2" |Object instance protocol
|}

Probably the most unusual and effective of the system primitive messages is the message become: otherObject. The response to this message is to swap the instance pointer of the receiver with that of the argument, otherObject. An example of the use of this message is found in the implementation of the message grow in several of the collection classes. The message grow is sent when the number of elements that can be stored in a (fixed-length) collection have to be increased without copyingthe collection; copying is undesirable because all shared references to the collection must be preserved. Thus a new collection is created, its elements stored, and then the original collection transforms into (becomes) the new one. All pointers to the original collection are replaced by pointers to the new one.

The following is the method for grow as specified in class SequenceableCollection.

<syntaxhighlight lang="smalltalk">
grow
| newCollection |
newCollection ← self species new: self size + self growSize.
newCollection replaceFrom: 1 to: self size with: self.
↑self become: newCollection
growSize
↑10
</syntaxhighlight>

Subclasses can redefine the response to the message growSize in order to specify alternative numbers of elements by which to expand.

==Notes==
<references />

[[Category:Smalltalk80LanguageImplementation]]

← Older revision		Revision as of 09:29, 9 May 2014
Line 130:		Line 130:


	Tests to see if an object is nil are handled in class Object, but reimplemented in UndefinedObject. In class Object, messages isNil and ~~notNii~~ are implemented as		Tests to see if an object is nil are handled in class Object, but reimplemented in UndefinedObject. In class Object, messages isNil and notNil are implemented as

	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
Line 189:		Line 189:
	\|or: alternativeBlock\|\|Nonevaluating disjunction. If the receiver is false, answer the value of the argument; otherwise, answer true without evaluating the argument.		\|or: alternativeBlock\|\|Nonevaluating disjunction. If the receiver is false, answer the value of the argument; otherwise, answer true without evaluating the argument.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock\|\|Conditional statement. If the receiver is true, answer the result of evaluating ~~trueAlternativeBtock~~; otherwise answer the result of evaluating falseAlternativeBlock.		\|ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock\|\|Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBlock; otherwise answer the result of evaluating falseAlternativeBlock.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock\|\|Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBlock; otherwise answer the result of evaluating ~~falseAlternativeClock~~.		\|ifFalse: falseAlternativeBlock ifTrue: trueAlternativeBlock\|\|Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBlock; otherwise answer the result of evaluating falseAlternativeBlock.
	\|- style="vertical-align:top;"		\|- style="vertical-align:top;"
	\|ifTrue: trueAlternativeBlock\|\|Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBlock; otherwise answer nil.		\|ifTrue: trueAlternativeBlock\|\|Conditional statement. If the receiver is true, answer the result of evaluating trueAlternativeBlock; otherwise answer nil.
Line 228:		Line 228:
	↑nil		↑nil
	ifFalse: falseAlternativeBlock		ifFalse: falseAlternativeBlock
	~~↑falseAtternativeBlock~~ value		↑falseAlternativeBlock value
	</syntaxhighlight>		</syntaxhighlight>

Line 384:		Line 384:


	The private initialization method is lights: numberOfLights. Each light is created turned off except for the first light. Then each light is connected to all the other lights (using the message addDependent:). The simulated ~~Traffickight~~ operates by some round robin, perhaps timed, sequencing through each light, turning it on. A simple example shown below creates the ~~Traffickight~~ with the first light on, and then turns on each of the other lights, one at a time. A simulation of a traffic corner might include different models for controlling the lights.		The private initialization method is lights: numberOfLights. Each light is created turned off except for the first light. Then each light is connected to all the other lights (using the message addDependent:). The simulated TrafficLight operates by some round robin, perhaps timed, sequencing through each light, turning it on. A simple example shown below creates the TrafficLight with the first light on, and then turns on each of the other lights, one at a time. A simulation of a traffic corner might include different models for controlling the lights.

	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">