war*_*ren 6 import programming-languages language-design include
Python和其他人使用import获取外部功能的技术.
C和其他人使用include(和,例如C++,有伴随的namespace头痛).
在设计语言时,选择一个(或使用Objective-C两者)的原因是什么？
我看到Apple正在通过一篇论文向LLVM提出一些更新/更改,并想知道为什么存在差异.
鉴于有多种方法可以实现import(在我回答之前我没有意识到),!include对比的整体好处是include什么？该import技术似乎只根据给定的路径找到单个子组件(至少在Python中 - 其[明显的]方法是我所知道的唯一方法).
该import方法的其他用途与此有何不同？何时使用"旧式" include方法在现代语言设计和实现中有意义(如果有的话)？
小智 9
C++和Objective C简单地继承的C的方法很容易定义和实现(简而言之,"当遇到一个#include,用文件的内容替换它,并继续"),但是有严重的问题.其中一些问题在您看过的演示文稿(以及其他地方)中有所说明.有成语和最佳实践(也在该演示文稿和其他地方讨论过)和次要扩展(#pragma once预编译头)可以缓解一些问题,但最终,这种方法基本上太有限了,无法处理软件工程师的工作期待一个模块系统.假装它做了更新的替代品(见下文)是一个相当漏洞的抽象.
如今,每个对语言设计有意见的人似乎都同意,如果你能提供帮助就不应该这样做.由于需要向后兼容性,C++和Objective C没有这个选择(尽管两者都有并且仍然可以选择添加另一种机制,而Objective C就是这样做的).这对于它来说是"公平的",因为这是一个相当不错的决定(当它有效时,它仍然有效,如果你有纪律),但世界已经转向并采取更好的方式将代码拆分为模块,然后将其重新组合在一起.(请注意,这种方式早在C日就已存在,但显然它们并没有流行一段时间.)
你所描述的" import技术" 实际上是一个非常大的设计空间.许多模块系统几乎(但并不完全)彼此完全不同 - 其余模块系统仍有足够的细微差别来毁掉你的一天.它可以是任何东西,从在新范围(Python,PHP)中执行导入的文件到完全成熟的ML风格的仿函数.有一些相似之处,因为所有这些模块系统都给每个"模块"(无论在相应系统中意味着什么)它们自己的范围/命名空间,(通常)允许单独编译模块,并且通常会不经意地修复它们. C风格文本的问题包括(或者创作者用替代方案看到的任何其他问题).这一般与人们可以说的一样多.