getModule
function, described on page 201, to get access to the ModuleClass
object itself, supplying the module's name as an interned NameClass
object. Here, the ModuleClass
object that represents module MyModule
is assigned to the global variable theModule
:
global theModule := getModule @mymodule
-- create a title container. theStartDir is the default for dir:
global tc := new TitleContainer path:"test.sx" dir:theStartDir
append tc (getModule @mymodule)
MyModule
outside of that module. What if the title container's startup action needs to refer to classes or objects that are defined in the module itself? The following code example demonstrates how to create a module and create the container that stores it within the same module. This example also saves that module to the title container without saving any variables that refer to the creation of the container.TopModule
. In this module, you create any classes and global variables that are to be stored with the module in your title or library container. module TopModule
uses ScriptX
end
in module TopModule
global topVar1 := "the first topVar"
class TopModuleTitle (TitleContainer)
instance variables
accessoryProtocols:#("string1", "string2", "stringEtc")
end
(
local tc := new TopModuleTitle \
dir:theScriptDir \
path:"modacct.sxt" \
name:"top"
append tc (getModule @TopModule)
tc.startUpAction := ( tc ->
print "here we go"
load tc[1]
print topVar1
)
close tc
)
Retrieving Objects from the Object Store
Saving Interfaces and Implementations
Figure 9-14: A network of modules to be saved
PaintInterface
and PaintImplementation
. In addition, it includes two clients of the PaintInterface
module that use its variables: PaintApplication
and DrawInterface
.PaintInterface
and PaintImplementation
) into a painting library. If you stored PaintInterface
first, the ScriptX object store would include all the other modules that use PaintInterface
-all the modules in the network.PaintImplementation
first, rather than PaintInterface
, prevents this sort of runaway storage of modules. Because implementation modules, by definition, are never used by any other modules, only the modules that the implementation module itself uses are stored.
This document is part of the ScriptX Language Guide, one of the volumes of the ScriptX Technical Reference Series. ScriptX is developed by the ScriptX Engineering Team at Apple Computer, successor to the Kaleida Engineering Team at Kaleida Labs, Inc.