qianqians'blog

Modules

发表于 分类于

Modules Reduce Clutter

A common problem in large systems is pollution of the global namespace: over time, as isolated systems are integrated, name clashes become quite likely. Slice provides the module construct to alleviate this problem:

大型系统中的一个常见问题是全局名称空间的污染：随着时间的推移，随着孤立的系统的集成，名称冲突变得很可能。 Slice 提供了模块构造来缓解这个问题：

1
2
3
4
5
6
7
8
9
10
11
module ZeroC 
{
    module Client 
    {
        // Definitions here...
    }
    module Server 
    {
        // Definitions here...
    }
}

A module can contain any legal Slice construct, including other module definitions. Using modules to group related definitions together avoids polluting the global namespace and makes accidental name clashes quite unlikely. (You can use a well-known name, such as a company or product name, as the name of the outermost module.)

模块可以包含任何合法的 Slice 构造，包括其他模块定义。 使用模块将相关定义分组在一起可以避免污染全局名称空间，并且不太可能发生意外的名称冲突。 （您可以使用众所周知的名称，例如公司或产品名称，作为最外层模块的名称。）

Modules are Mandatory

Slice requires all definitions to be nested inside a module, that is, you cannot define anything other than a module at global scope. For example, the following is illegal:

Slice 要求所有定义都嵌套在模块内，也就是说，您不能在全局范围内定义除模块之外的任何内容。 例如，以下行为是非法的：

1
2
3
4
interface I   // Error: only modules can appear at global scope
{
    // ...
}

Definitions at global scope are prohibited because they cause problems with some implementation languages (such as Python, which does not have a true global scope).

禁止在全局范围内进行定义，因为它们会导致某些实现语言（例如 Python，它没有真正的全局范围）出现问题。

Throughout the Ice manual, you will occasionally see Slice definitions that are not nested inside a module. This is to keep the examples short and free of clutter. Whenever you see such a definition, assume that it is nested in module M.

在整个 Ice 手册中，您偶尔会看到未嵌套在模块内的 Slice 定义。 这是为了保持示例简短且整洁。 每当您看到这样的定义时，请假设它嵌套在模块 M 中。

Reopening Modules

Modules can be reopened:

可以重新打开模块：

1
2
3
4
5
6
7
8
9
10
11
module ZeroC
{
    // Definitions here...
}
 
// Possibly in a different source file:
 
module ZeroC // OK, reopened module
{  
    // More definitions here...
}

Reopened modules are useful for larger projects: they allow you to split the contents of a module over several different source files. The advantage of doing this is that, when a developer makes a change to one part of the module, only files dependent on the changed part need be recompiled (instead of having to recompile all files that use the module).

重新打开的模块对于较大的项目很有用：它们允许您将模块的内容拆分为多个不同的源文件。 这样做的好处是，当开发人员对模块的一部分进行更改时，只需重新编译依赖于更改部分的文件（而不需要重新编译使用该模块的所有文件）。

Module Mapping

Modules map to a corresponding scoping construct in each programming language. (For example, for C++ and C#, Slice modules map to namespaces whereas, for Java, they map to packages.) This allows you to use an appropriate C++ using or Java import declaration to avoid excessively long identifiers in your source code.

模块映射到每种编程语言中相应的作用域构造。 （例如，对于 C++ 和 C#，Slice 模块映射到命名空间，而对于 Java，它们映射到包。）这允许您使用适当的 C++ using 或 Java import 声明来避免源代码中的标识符过长。

The Ice Module

APIs for the Ice run time, apart from a small number of language-specific calls that cannot be expressed in Ice, are defined in the Ice module. In other words, most of the Ice API is actually expressed as Slice definitions. The advantage of doing this is that a single Slice definition is sufficient to define the API for the Ice run time for all supported languages. The respective language mapping rules then determine the exact shape of each Ice API for each implementation language.

We will incrementally explore the contents of the Ice module throughout this manual.

Ice 运行时的 API，除了少数无法在 Ice 中表达的特定于语言的调用之外，均在 Ice 模块中定义。 换句话说，大部分 Ice API 实际上都是表达为 Slice 定义的。 这样做的优点是单个 Slice 定义足以为所有支持的语言定义 Ice 运行时的 API。 然后，相应的语言映射规则确定每种实现语言的每个 Ice API 的确切形态。

我们将在本手册中逐步探索 Ice 模块的内容。