Using dynamic code generation, Slice files are “loaded” at run time and dynamically translated into Ruby code, which is immediately compiled and available for use by the application. This is accomplished using the
Ice::loadSlice method, as shown in the following example:
For this example, we assume that Color.ice contains the following definitions:
module M {
enum Color { red, green, blue };
};
The Ice::loadSlice method behaves like a Slice compiler in that it accepts command-line arguments for specifying preprocessor options and controlling code generation. The arguments must include at least one Slice file.
def loadSlice(cmd, args=[])
The command-line arguments can be specified entirely in the first argument, cmd, which must be a string. The optional second argument can be used to pass additional command-line arguments as a list; this is useful when the caller already has the arguments in list form. The function always returns
nil.
For example, the following calls to Ice::loadSlice are functionally equivalent:
Ice::loadSlice("‑I/opt/IceRuby/slice Color.ice")
Ice::loadSlice("‑I/opt/IceRuby/slice", ["Color.ice"])
Ice::loadSlice("", ["‑I/opt/IceRuby/slice", "Color.ice"])
This function attempts to locate the slice subdirectory of your Ice installation using an algorithm that succeeds for the following scenarios:
If the slice subdirectory can be found,
getSliceDir returns its absolute path name, otherwise the function returns
nil.
Alternatively, you can call Ice::loadSlice several times:
If a Slice file includes another file, the default behavior of Ice::loadSlice generates Ruby code only for the named file. For example, suppose
Syscall.ice includes
Process.ice as follows:
If you call Ice::loadSlice("‑I. Syscall.ice"), Ruby code is not generated for the Slice definitions in
Process.ice or for any definitions that may be included by
Process.ice. If you also need code to be generated for included files, one solution is to load them individually in subsequent calls to
Ice::loadSlice. However, it is much simpler, not to mention more efficient, to use the
‑‑all option instead:
When you specify ‑‑all,
Ice::loadSlice generates Ruby code for all Slice definitions included directly or indirectly from the named Slice files.
There is no harm in loading a Slice file multiple times, aside from the additional overhead associated with code generation. For example, this situation could arise when you need to load multiple top-level Slice files that happen to include a common subset of nested files. Suppose that we need to load both
Syscall.ice and
Kernel.ice, both of which include
Process.ice. The simplest way to load both files is with a single call to
Ice::loadSlice:
Although this invocation causes the Ice extension to generate code twice for Process.ice, the generated code is structured so that the interpreter ignores duplicate definitions. We could have avoided generating unnecessary code with the following sequence of steps:
In more complex cases, however, it can be difficult or impossible to completely avoid this situation, and the overhead of code generation is usually not significant enough to justify such an effort.
The Ice::loadSlice method must be called outside of any module scope. For example, the following code is incorrect:
# WRONGmodule M
Ice::loadSlice(
"‑‑all ‑I. Syscall.ice Kernel.ice")
...
end
You should be familiar with static code generation if you have used other Slice language mappings, such as C++ or Java. Using static code generation, the Slice compiler
slice2rb (see
Section 26.15.4) generates Ruby code from your Slice definitions.
For each Slice file X.ice,
slice2rb generates Ruby code into a file named
X.rb in the output directory. The default output directory is the current working directory, but a different directory can be specified using the
‑‑output‑dir option.
It is important to understand how slice2rb handles include files. In the absence of the
‑‑all option, the compiler does not generate Ruby code for Slice definitions in included files. Rather, the compiler translates Slice
#include statements into Ruby
require statements in the following manner:
3.
Replace the .ice extension with
.rb. Continuing our example from the previous step, the translated
require statement becomes
As a result, you can use ‑I options to tailor the
require statements generated by the compiler in order to avoid absolute pathnames and match the organizational structure of your application’s source files.
The requirements of your application generally dictate whether you should use dynamic or static code generation. Dynamic code generation is convenient for a number of reasons:
You can safely use a combination of static and dynamic translation in an application. For it to work properly, you must correctly manage the include paths for Slice translation and the Ruby interpreter so that the statically-generated code can be imported properly by
require.
#include <Glacier2/Session.ice>
module MyApp {
interface MySession extends Glacier2::Session {
// ...
};
};
Whether the included file Glacier2/Session.ice is loaded dynamically or statically is determined by the presence of the
‑‑all option:
sliceDir = "‑I#{ENV['ICE_HOME']}/slice"
# Load Glacier2/Session.ice dynamically:
Ice::loadSlice(sliceDir + " ‑‑all MySession.ice")
# Load Glacier2/Session.ice statically:
Ice::loadSlice(sliceDir + " MySession.ice")
In this example, the first invocation of loadSlice uses the
‑‑all option so that code is generated dynamically for all included files. The second invocation omits
‑‑all, therefore the Ruby interpreter executes the equivalent of the following statement:
As a result, before we can call loadSlice we must first ensure that the interpreter can locate the statically-generated file
Glacier2/Session.rb. We can do this in a number of ways, including
26.15.4 slice2rb Command-Line Options
The Slice-to-Ruby compiler, slice2rb, offers the following command-line options in addition to the standard options described in
Section 4.20:
