3
为什么.NET模块将模块文件名与名称空间分开?
在Scheme编程语言(R6RS标准)的实现中,我可以如下导入模块: (import (abc def xyz)) 系统将尝试寻找一个文件$DIR/abc/def/xyz.sls,该文件$DIR是您保存Scheme模块的某个目录。xyz.sls是模块的源代码,如有必要,它可以即时进行编译。 在这方面,Ruby,Python和Perl模块系统相似。 另一方面,C#涉及更多。 首先,您必须根据每个项目引用dll文件。您必须明确引用每个。这比说要复杂得多,将dll文件拖放到目录中,然后让C#按名称进行选择。 其次,dll文件名与dll提供的名称空间之间没有一一对应的命名关系。我可以体会这种灵活性,但是它也可以一发不可收拾。 为了具体化,如果我说这话using abc.def.xyz;,C#会尝试abc/def/xyz.dll在C#知道要查找的某个目录中找到一个文件(可以根据每个项目进行配置),那就太好了。 我发现处理模块的Ruby,Python,Perl,Scheme方法更加优雅。新兴语言似乎倾向于更简单的设计。 为什么.NET / C#世界以额外的间接级别以这种方式执行操作?