没有Ambuguity的命名空间规范

Question

为什么某些语言(如C++和Python)需要指定对象的命名空间,即使不存在歧义？我知道有这样的后门,比如using namespace x在C++或from x import *Python中.但是,当只有一个可访问的命名空间包含给定的标识符且不存在歧义时,我无法理解不希望语言只是"做正确的事"的理由.对我来说,这只是不必要的冗长和违反DRY,因为你被迫指定编译器已经知道的东西.

例如:

import foo  # Contains someFunction().

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

比.

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认为"显式优于隐式".(输入import thispython解释器)

另外,说我正在读某人的代码.也许这是你的代码; 也许这是我六个月前的代码.我看到了一个参考bar().功能来自哪里？我可以通过文件查看def bar(),但如果我找不到它,那么呢？如果python自动找到通过导入可用的第一个bar(),那么我必须搜索导入的每个文件以找到它.太痛苦了!如果函数发现通过导入heirarchy进行递归怎么办？

我宁愿看到zomg.bar(); 它告诉我函数的来源,并确保在代码更改时我总是得到相同的函数(除非我更改zomg模块).

Answer 3

问题在于抽象和重用：您真的不知道将来是否不会有任何歧义。

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

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

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

如果在特定范围内使用use，则完全不会违反DRY规则。