As a Sling parser recognizes an input program, it must build a composite command that represents the program. Assembler subclasses do the work of building this command, sharing certain objects during parsing. The assemblers use a target object to contain the common objects the assemblers need while parsing a Sling program. The target is a single object of class SlingTarget containing a scope, two sliders, and a RenderableCollection object. The assemblers update the target and leave one or more Command objects on the assembly's stack. Figure 16.27 shows the SlingTarget class.
Figure 16.27. The SlingTarget class. An instance of SlingTarget holds objects that the environment's assemblers refer to while constructing a command that represents a user 's program.
A SlingTarget is created by a mediator when the user enters a program and clicks the Go! button. The classes in sjm.examples.sling divide the task of providing an interactive development environment into two parts . The SlingIDE class has all the user interface components , and the SlingMediator class handles all the component interactions. When the user clicks Go!, the mediator checks that the program text has changed since any previous parse. If the text is new, the mediator creates a new SlingTarget object by feeding the SlingTarget constructor the two sliders from the user interface. Assemblers refer to these sliders whenever the user's program references s1 or s2 . In addition to the sliders, a new target object starts with an empty RenderableCollection object and an empty Scope .
A target's Scope object is a dictionary of variables , and a target's RenderableCollection object is a collection of plottable functions. A Renderable object combines two Sling functions: One is the function to plot (or render), and the other one represents the number of lines to use in the plot.
The RenderableCollection object remains empty throughout the parsing phase. When the parser sees a plot command, a PlotAssembler object pulls the RenderableCollection object from the target and uses it to create an AddFunctionCommand . When the mediator executes the command during the execution phase, the command adds a function to the RenderableCollection object.
Consider the Sling program
nLine = 5; plot sling(1, 1); plot sling(1, 2);
When the parser parses a plot command, the parser first uses an assembler to stack the sling function, and then the parser asks a PlotAssembler to work on the assembly. The assembler pops the function, looks up the target's RenderableCollection object and nLine variable, and uses the function, the number of lines, and the collection to create a new AddFunctionCommand . The sample program plots two functions, each of which appears in the target's RenderableCollection object after the AddFunctionCommand object executes.
After a parser completes its parse of a user's program, the target itself is no longer useful. Its purpose is to act as a central storage place for the scope, sliders, and function collection that the parser builds. The Sling environment's various assemblers wire the target's contents to commands that the assemblers leave on the assembly's stack.