没有歧义的命名空间规范

Question

为什么某些语言（如 C++ 和 Python）要求指定对象的命名空间，即使不存在歧义？ 我知道这其中存在后门，例如 C++ 中的 using namespace x 或 Python 中的 from x import *。 然而，当只有一个可访问的命名空间包含给定的标识符并且不存在歧义时，我无法理解不希望语言只是“做正确的事情”背后的基本原理。 对我来说，这只是不必要的冗长和违反 DRY 的行为，因为你被迫指定编译器已经知道的东西。

例如：

import foo  # Contains someFunction().

someFunction()  # imported from foo.  No ambiguity.  Works.

VS。

import foo  # Contains someFunction()
import bar  # Contains someFunction() also.

# foo.someFunction or bar.someFunction?  Should be an error only because
# ambiguity exists.
someFunction() 

Answer 1

原因之一是防止稍后更改代码时（或者对于外部模块/库，当其他人更改代码时）意外引入冲突。 例如，在 Python 中，

from foo import *
from bar import *

如果您知道模块 foo 和 bar 没有任何同名的变量，那么您的编写就不会发生冲突。 但是，如果在更高版本中 foo 和 bar 都包含名为 rofl 的变量怎么办？ 然后 bar.rofl 将在您不知情的情况下覆盖 foo.rofl。

我还希望能够查看文件顶部并准确查看正在导入的名称以及它们来自何处（当然，我说的是 Python，但同样的推理也适用于 C++） 。

Answer 2

Python 认为“显式优于隐式”。
（在 python 解释器中输入import this）

另外，假设我正在阅读某人的代码。 也许这是你的代码； 也许这是我六个月前的代码。 我看到对 bar() 的引用。 函数从哪里来？ 我可以在文件中查找 def bar()，但如果找不到它，那怎么办？ 如果 python 通过导入自动查找第一个可用的 bar() ，那么我必须搜索导入的每个文件才能找到它。 多么痛苦啊！ 如果函数查找通过导入层次结构递归会怎样？

我宁愿看到 zomg.bar(); 它告诉我该函数来自哪里，并确保在代码更改时我始终得到相同的函数（除非我更改 zomg 模块）。

Answer 3

问题在于抽象和重用：你真的不知道未来是否会出现任何歧义。

例如，在项目中设置不同的库只是为了发现它们都有自己的字符串类实现（称为“string”），这是很常见的。
如果库没有封装在单独的命名空间中，编译器就会抱怨存在歧义。

然后，通过指定您想要在每个特定指令或上下文（阅读：作用域）中使用的实现（如标准 std::string ）来避免这种歧义，这是一种令人愉快的乐趣。

如果您认为这在特定上下文中是显而易见的（请阅读：在 c++ 中的特定函数或 .cpp 中，在 python 中.py 文件 - 永远不要在 C++ 头文件中）您只需表达自己并说“它应该是显而易见的”，添加“使用命名空间”指令（或 import *）。 直到编译器抱怨，因为它不是。

如果您在特定范围内使用 using，则根本不会违反 DRY 规则。

Answer 4

有些语言的编译器试图“做正确的事”——我想到的是 Algol 和 PL/I。 它们不再存在的原因是编译器非常不擅长做正确的事情，但非常擅长做错误的事情，只要有一半的机会！

Answer 5

该规则力求的理想目标是使创建可重用组件变得容易 - 如果您重用组件，您只是不知道哪些符号将在客户端使用的其他命名空间中定义。 因此，该规则迫使您对于您尚不了解的进一步定义明确您的意图。

然而，C++ 还没有达到这个理想，主要是因为 Koenig 查找。

Answer 6

这真的是正确的事情吗？

如果我有两种类型 ::bat 和 ::foo::bar

我想引用 bat 类型但不小心按了 r 键而不是 t （它们彼此相邻）怎么办？

编译器在每个命名空间中搜索以找到 ::foo::bar 而不给我任何警告是“正确的事情”吗？

或者，如果我在我的代码库中使用“bar”作为“::foo::bar”类型的简写，会怎么样。
然后有一天，我添加了一个定义 ::bar 数据类型的库。 突然之间出现了一种以前没有的歧义。 突然间，“正确的事情”变成了错误。

在这种情况下，编译器要做的正确事情是假设我的意思是我实际编写的类型。 如果我编写没有命名空间前缀的 bar，它应该假设我引用的是全局命名空间中的类型 bar。 但如果它在我们假设的场景中这样做，它会改变我的代码引用的类型，甚至不会提醒我。

或者，它可能会给我一个错误，但是来吧，这太荒谬了，因为即使使用当前的语言规则，这里也不应该有歧义，因为其中一种类型隐藏在我没有的命名空间中指定，所以不应该考虑。

另一个问题是编译器可能不知道还存在哪些其他类型。 在 C++ 中，定义的顺序很重要。

在 C# 中，类型可以在单独的程序集中定义，并在代码中引用。 编译器如何知道另一个具有相同名称的类型不存在于另一个程序集中，只是存在于不同的命名空间中？ 它如何知道稍后不会将其添加到另一个程序集中？

正确的做法是做那些给程序员带来最少麻烦的事情。 根据不完整的数据对程序员进行事后猜测通常不是正确的做法。

大多数语言都提供了多种工具来避免指定名称空间。

在 C++ 中，您有“使用命名空间 foo”以及 typedef。 如果您不想重复命名空间前缀，那就不要这样做。 使用该语言提供的工具，这样您就不必这样做。

Answer 7

这一切都取决于你对“正确的事情”的定义。 如果只有一个匹配项，编译器猜测您的意图是否正确？

双方都有论据。

Answer 8

有趣的问题。 就 C++ 而言，正如我所见，如果编译器在发生冲突时立即标记错误，则可能导致的唯一问题是：

所有 C++ 命名空间的自动查找将消除隐藏的能力库代码内部部分的名称。

库代码通常包含永远不会对“外部世界”可见的部分（类型、函数、全局变量）。 C++ 之所以有未命名的命名空间，是为了避免“内部部分”堵塞全局命名空间，即使这些库命名空间是使用 using namespace xyz; 显式导入的。

示例：假设 C++ 确实进行了自动查找，并且 C++ 标准库的特定实现包含一个内部辅助函数 std::helper_func()。 假设用户 Joe 使用不包含 std::helper_func() 的不同库实现开发了一个包含函数 joe::helper_func() 的应用程序code>，并使用对 helper_func() 的非限定调用来调用他自己的方法。 现在，Joe 的代码可以在他的环境中正常编译，但任何其他尝试使用第一个库实现来编译该代码的用户都会遇到编译器错误消息。 因此，要使 Joe 的代码可移植，首先需要插入适当的 using 声明/指令或使用完全限定的标识符。 换句话说，自动查找对于可移植代码来说没有任何好处。

诚然，这似乎不是一个经常出现的问题。 但是，由于输入显式 using 声明/指令（例如 using namespace std;）对于大多数人来说并不是什么大问题，因此完全解决了这个问题，并且是可移植开发所必需的不管怎样，使用它们（呵呵）似乎是一种明智的做事方式。

注意：正如 Klaim 指出的，您在任何情况下都不会想要依赖头文件内的自动查找，因为这会立即阻止您的模块在以下位置使用：与任何包含冲突名称的模块同时发生。 （这只是为什么你不在 C++ 中的头文件中使用 using namespace xyz; 的逻辑扩展。）