缺少Ambuguity的命名空间规范

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类实现，这是很常见的，称为"string“。然后，如果库没有封装在单独的名称空间中，编译器会抱怨有歧义。

然后，通过指定要在每个特定指令或上下文(read : scope)中使用的实现(就像标准的std::string one)来避免这种模棱两可，这是一件令人愉快的事情。

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

如果您在特定的作用域中使用using，则根本不会违反DRY规则。